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ABSTRACT 

The military is heavily reliant on the transfer of information among various 
networks in its day-to-day operations. With fewer defense dollars available for the 
development of new systems, the use of commercial-off-the-shelf (COTS) hardware to 
build military information networks is becoming commonplace. The critical nature of 
much of this information requires that knowledge of the performance characteristics of 
the networks through which this information travels be known. These characteristics 
allow network managers and designers to plan for future growth of the network, analyze 
network reliability, and plan for the construction of new networks. 

One method to determine the performance characteristics of a network is through 
the use of modeling and simulation. COMNET m release 1. In is a COTS network 
simulation application which may be used to model and simulate both local and wide 
area networks. This thesis provides a tutorial to explain the theory used in the application 
for the modeling and simulation of networks. Each chapter presents the theory of several 
objects which may be used in the application, states a network problem which is to be 
analyzed, provides step-by-step instructions to build a model to analyze the network 
problem, and presents the results of the network simulation. 
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EXECUTIVE SUMMARY 


The military is heavily reliant on the transfer of information among various 
networks in its day-to-day operations. With fewer defense dollars available for the 
development of new systems, the use of commercial-off-the-shelf (COTS) hardware to 
build military information networks is becoming commonplace. The critical nature of 
much of this information requires that knowledge of the performance characteristics of 
the networks through which this information travels be known. These characteristics 
allow network managers and designers to plan for future growth of the network, analyze 
network reliability, and plan for the construction of new networks. 

One method to determine the performance characteristics of a network is through 
the use of modeling and simulation. COMNET in release 1. In is a COTS network 
simulation application which may be used to model and simulate both local and wide 
area networks. This application was developed by CACI Product Inc. using an object- 
oriented framework. The application does not model every piece of network hardware 
which is available for actually building a physical network. Instead, the application uses 
several generic objects whose parameters may be set within the application to model a 
physical piece of network hardware. The application allows several methods of 
generating the traffic which is carried on the modeled networks. Commands which model 
various processes which could occur on a node such as writing or reading to a local disk, 
processing data, and transporting a message may be defined and built to model the 
activity which occurs on network nodes. In addition, traffic captured from an actual 
network may be imported into a model. The common thread involved in modeling either 
network hardware or message traffic is the ability to describe the parameters available in 
modeling each object by either a constant value or a statistical distribution. 

This thesis provides a tutorial to explain the theory used in the application for the 
modeling and simulation of networks. Each chapter presents the theory of several objects 
which may be used in the application, states a network problem which is to be analyzed, 
provides step-by-step instructions to build a model to analyze the network problem, and 
presents the results of the network simulation. 
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The models which are presented are primarily based on actual network problems 
or concerns of the Systems Technology Lab’s ethemet and FDDI networks. Each model 
emphasizes the theory of the objects covered in a chapter. A hypothetical company 
network model is used to demonstrate the applicability of traffic sources available in the 
application and provide an introduction to using the COMNET III graphical user 
interface.. A model of a World Wide Web server and the effects of hard disk 
performance in responding to HTTP requests is used to demonstrate the capabilities of 
the computer and communications node. A model based on shifting a peer-to-peer 
network to a client-server architecture demonstrates the ability to build application 
sources and shows the additional network traffic which would occur. A model of the 
System Technology Lab’s ethemet network demonstrates the ability to import message 
traffic to analyze network problems. Another model of the System Technology Lab’s 
ethemet network performs a what-if analysis which is used to ascertain network 
performance after segmenting of the network using router nodes. The final model deals 
with the ability to transmit multicast video traffic across frame relay networks, and 
demonstrates the ability to model wide area networks (WANs) using either point-to-point 
links and ATM switches or by using the WAN cloud object. 
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I. INTRODUCTION 


A. MILITARY AND CIVILIAN SECTORS RELIANCE ON NETWORKS 

The trend in both the civilian and the military sectors has been toward a heavy 
reliance on information networks in their day-to-day operations. This trend has been 
fueled by the rapid advances in information systems technology. As a result, society has 
shifted away from the production-based system to a system where the ability to 
transport information to the necessary destinations at the needed time and in a format 
which can be quickly digested by either man or machine is the key to both corporate and 
military success. This is especially true in the military as its paradigm is rapidly changing 
from the Carl von Clausewitz theory of massing combat power in order to overwhelm the 
enemy to that of a global infosphere where data concerning the enemy may be transferred 
to the necessary location to deliver a precision strike against the enemy without requiring 
the classical massing of forces. The dependence on networks within the military can best 
be described by General Colin L. Powell’s assessment in June of 1992 of the use of 
networks during the Persian Gulf War: 

At the height of the Persian Gulf conflict, the automated message information network 
passed nearly 2 million packets of information per day through gateways in the Southeast 
Asia theater of operations. Efficient management of the information increased the pace of 
combat operations, improved decisionmaking, and synchronized various combat 
capabilities. The technology developed to support these networks proved to be a vital 
margin that saved lives and helped achieve victory.[Ref 1] 

B. COMMAND, CONTROL, COMPUTER, COMMUNICATION (C4) SYSTEMS 
AND THE NEED FOR NETWORK SIMULATION 

The trend in both the civilian and military sectors is toward the building of 
information systems using an open systems architecture. The result of this trend in the 
military is a shift from single purpose, non-interoperable systems to systems which are 
similar or have already been fielded in commercial applications. The Global Command 
and Control System (GCCS) is a good example of this trend as it incorporates an open 
systems architecture with proven commercially developed networking technology in a 
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system which provides the necessary communications from the National Command 
Authority to the regional military Commanders-in-Chief (CINC). 

The basic requirements of any C4 system is the ability to provide robust 
communications which are interoperable with other systems, flexible, responsive, 
survivable, and sustainable. The basic building blocks to give the network these 
characteristics are terminal devices, transmission media, switches, control and 
management [Ref. 1]. Terminal devices may best be described as the pieces of equipment 
which are used to generate and receive messages whether by computer, telephone, 
facsimile device, etc. Transmission medium is the pipe or path over which the message is 
sent. Switching is the means by which traffic is routed over the network to reach its 
intended destination. The final building block of control and management consists of the 
following seven functions [Ref 1]: 

1. Technical Management and Direction 

2. Management of C4 Resources 

3. Network Performance Analysis 

4. Fault Isolation 

5. Security 

6. Network Planning and Engineering 

7. Configuration Management 

From the list of functions required by network control and management, the three 
functions of network performance analysis, fault isolation, and network planning and 
engineering lend themselves directly to the area of network simulation. 

Network simulation can be a valuable tool as it provides a manner of modeling a 
network to determine its performance characteristics. Often, due to the critical nature of a 
network, the ability to disconnect the network for testing and evaluation or upgrades is 
not an option or must be scheduled during periods of minimal usage. Network simulation 
provides a means of testing proposed changes prior to placing them into effect, 
performing what-if analysis concerning the reliability of key components in a network 
and the effects of losing a component, planning for future growth, and initial design of a 
proposed network. The costs associated with the building and operating of a network 
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make simulation a viable option in making choices in the building, modification, and 
performance analysis of a network. 

C. THESIS SCOPE 

There are many commercial off-the-shelf network simulation applications 
available on the market today. The focus of this thesis is on one of these applications. 
COMNET in release 1. In is a network simulation tool develop by CACI Products Inc. 
which may be used in the simulation of both voice and data networks. The scope of this 
thesis will be the development of a tutorial which deals only in the area of using this 
application in the modeling of data networks. Specific areas which will be looked at are 
the modeling of local area networks and packet-switched wide area networks, and the 
methods of generating traffic in this application. 

The objective of the tutorial is to use a building block method where each chapter 
of the tutorial focuses on a particular aspect or modeling construct which the application 
provides. Each chapter in the tutorial will use the following format: 

1. The objective of the chapter will be stated. 

2. COMNET ni constructs and theory which will be used in the chapter will be 
presented. 

3. A network problem description will then be stated. 

4. Analysis which was performed in determining characteristics of network 
equipment or traffic sources will be covered. 

5. Step-by-step instructions for building a model to analyze the problem 
statement will be given. 

D. COMNET HI OVERVIEW 

COMNET in is a commercial off-the-shelf application whose function is to allow 
users to estimate the performance characteristics of computer based networks. A network 
description is created graphically using a window interface, and no actual programming is 
required of the user. The application was formulated primarily for the modeling of both 
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Wide Area Networks (WANs) and Local Area Networks (LANs). The recommended 
usage of the application include [Ref. 2 p. 5, 6]: 

• Peak loading studies 

• Network sizing at the design stage 

• Resilience and contingency planning 

• Introduction of new users/applications 

• Evaluating performance improvement options 

• Evaluating grade of service contracts. 

The COMNET HI application was written in the programming language 
MODSEM n using an object-oriented design. As such, objects are created within the 
application which represent various pieces of hardware that may be found in a network. In 
writing the program using an object-oriented framework, creating representations of all 
types of equipment which could be present in a network would be very difficult. The 
program instead was written with several objects or basic building blocks whose 
characteristics may be edited to match those of equipment found in a real world network. 
These building blocks which include computer and communication nodes, router nodes, 
ATM nodes, and links may all be edited to define the characteristics of the piece of 
hardware which is desired to be modeled. 

The basic steps to build a model using the application are to first define a network 
topology using the various nodes and links available in the application. The traffic 
loading and computer workload are then established by creating application sources, 
traffic sources, or by the direct input of traffic gathered from an actual network using a 
protocol analyzer. The model is then verified for its correctness and a simulation may be 
run. At the completion of a simulation, reports are generated which describe the 
performance of the modeled network. 
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II. COMNET m BASICS 


A. INTRODUCTION 

The purpose of this chapter is to provide an introduction to the COMNET HI 
graphical user interface and the methods for creating, editing, and manipulating objects 
using this interface. Also, aspects concerning the running of a simulation and the reports 
and statistics which may be obtained from running a network simulation will be covered. 

B. COMNET III GRAPHICAL USER INTERFACE 

COMNET in uses a standard Windows*™ interface for the creation of networks 
models. Figure 2.1 displays the view which appears when initially starting the 
application. The standard menu format of most windowed applications across the top of 
the window activates pull down menus. The toolbar to the left hand side of the screen 
allows for a simple method of creating objects in a model. The area to the right of the 
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Figure 2.1 View of COMNET HI Graphical User Interface 
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toolbar is the work area where models are built. The small strip below the toolbar and the 
workspace is used to display messages to the user concerning actions performed while 
using the application. 

C. COMNET III MENUS 

The menu bar across the top of the window activates drop down lists which 
present the options available for a menu option. The following subsections present brief 
descriptions of each menu followed by a list of commands available in the menu option 
which may be used for the manipulation of objects within a model. 

1. File Menu 

This menu is used primarily for the manipulation of files which may be created 
and imported within the application. The menu options are as follows 
[Ref. 2 p. 210, 211]; 

• New. Clears the current model and creates a new clean workspace for the 
creation of a new model. If a model is in the workspace, the application 
prompts the user to cancel this operation before it is carried out. 

• Open: Used to open an existing model. All COMNET m model file have a 
filename followed by a .c3 extension. 

• Save: Used to save the current model. 

• Save As: Saves the current model to the path and directory specified by the 
user. 

• Import: Allows importing a model which was created in an application other 
than COMNET ID. Currently, the application allows importing network 
topology files only from HP OpenView, Cabletron Spectrum, and IBM 
Netview 6000. 

• Export: Used primarily to export simulation statistics from the COMNET HI 
format to a tab-delimited format which can be recognized by most spreadsheet 
applications. When the simulation statistics option from the export option is 
selected a tab-delimited file called statfile.xpt is created. 
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• Print: Prints a picture of the current model layout. 

• Exit: Exits the application. 

2. Edit Menu 

The options available from this menu are used for the manipulation of objects 
created in a model and are as follows [Ref. 2 p. 211, 212]: 

• Cut: Deletes the selected object and places it on the clipboard. 

• Copy : Places a copy of the selected object on the clipboard so that it can be 
used later in a Paste operation. 

• Paste: Places a copy of an object which has been placed on the clipboard in 
the location specified by the user. 

• Copy Paste: The same function as a Copy followed by Paste operation. 

• Clear: Deletes the selected object. 

• Clone: Provides a method of creating duplicate copies of an object. When 
selected a window will appear as shown in Figure 2.2. Enter the number of 
clones desired and the X and Y offset and press the OK button. Duplicates of 
the original will then be made positioned according to the X and Y offset from 
the original. 



Figure 2.2 Clone Window 

• Select All: Selects every object in the workspace. 

• Scale: Used to scale the size of all icons selected when this option is chosen. 
The user may specify the scaling factor based on the needs of the model. 
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• Move: Allows several objects which have been selected to be moved to a new 
position in the work area while maintaining there relative position to each 
other. 

• Detail: Used to bring up the dialog window which allows editing of an object. 
Double clicking on the object will bring up the same window. 

• Parent: Used to define the routing method of the highest level in a network. 

• Enter: Used to display the screen of a sub-network for building the sub¬ 
network. Double clicking on the sub-network icon will accomplish the same 
function. 

• Leave: Returns to a the main model layout from a subnetwork or a WAN 
cloud object. 

3. View Menu 

The view menu is primarily used to edit the look and size of the work area. The 
options which are available include [Ref. 2 p. 212]: 

• Zoom In : Allows the user to zoom in on a given selected portion of the 
model. After selecting this option, single click to the upper left of the area to 
zoom in on. Then, drag the mouse to define the area. A rectangular box will 
appear on the screen showing the area which will be zoomed into. When the 
area is defined, single click again and the screen will zoom into the selected 
area. 

• Zoom Out: Expands the view to take in the entire work area. 

• Zoom Reset: Sets the zoom to the size of the original work area. 

• Set Work Area Size: The default work area size is a square consisting of the 
size of the screen of the computer which the application is run on. Selecting 
this option brings up a window as shown in Figure 2.3 which allows scaling 
the work area to meet the needs of the model being built. A scale factor of two 
will double the size of the X and Y axis. The adjust content box, if selected, 
will stretch the objects to fit the size of the new work space if selected. 
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Figure 2.3 Work Area Scaling Window 


• Set Color: Selection of this option brings up a window such as in Figure 2.4 
which allows setting the color of the background and foreground in the 
workspace. Foreground sets the color of the text in the work area. Background 
sets the color of the background in the work area. Different color schemes may 
be used within the same model between the backbone network view and 
subnetwork views. 



Figure 2.4 Work Area Color Window 

• Toggle Names: Turns the names of all icons within the model on or off in the 
work area. 


4. Create Menu 

The primary objective of this menu is the creation of objects to build a model. The 
drop down menu contains a list of all objects. When an object is selected, the outline of 
the object appears by the mouse cursor. By moving the cursor to the desired position on 
the workspace and single clicking, the icon of that object appears. All objects which may 
be created using this menu may also be more easily created using the toolbar which is 
discussed in Section D of this chapter. 
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5. Define Menu 

This menu is used to define global parameters or characteristics of any object 
which may be created within the application. The selection of any of the options within 
this menu brings up a window which allows editing of the parameters for a given type of 
object. These parameters will then be available to any object for selection when later 
editing the object. 

6. Simulation Menu 

The simulation menu provides options which allow setting the parameters which 
govern the running of a simulation. Aspects of simulation and the options available in this 
menu are covered in detail in Section I of this chapter. 

7. Report Menu 

This menu allows the selection of those objects within a model for which statistic 
are desired to be gathered when running a simulation. The method of selecting the reports 
chosen and the options available are covered in Section G of this chapter. 

8. Archive Menu 

COMNET in maintains a list of all objects and parameter sets with there default 
values. When an object is initially created, these default values are used as the parameters 
which describe any object, and only the parameters which are maintained in the archive 
list may be selected. Objects or parameters entered into a model are not automatically 
archived for use in subsequent models. The archive menu allows the user to manipulate 
these default values or to enter user-defined parameters for commonly-used objects. 
Objects and parameters which are explicitly entered via the archive menu will be 
available to any other model which the user may build. 

9. Help Menu 

The COMNET in help menu is limited in scope. It contains useful information 
about each of the menu options, which is useful as an online reference, and information 
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concerning the manipulation and creation of objects. Detailed information on the objects 
and their parameters is not included within the Help menu. 


D. COMNET III TOOLBAR 

The toolbar, located to the left hand side of the program window, facilitates the 
creation of the network model topology, traffic sources, and application sources. It offers 
the same function as the Create menu but is often easier to use as it provides a simple one 
button point and click creation. Figure 2.5 displays the toolbar along with the name of 
each button on the toolbar. 
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Figure 2.5 COMNET HI Toolbar 


The toolbar has two modes of operation, standard and extended. Standard mode is 
the default mode where a single click on a button activates that button. The object may 
then be placed in the work area by either depressing the mouse button and dragging the 
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object to its desired position or moving the mouse to the desired position and single 
clicking again. Extended mode is activated by double clicking on a button. The button 
will then appear to be further depressed to indicate that extended mode is in use. Multiple 
objects can now be created by positioning the mouse where the object is desired to be 
placed and single clicking. To place the toolbar back into standard mode when finished 
creating the multiple objects, simply depress the Selection Tool button on the toolbar. 

E. TERMINOLOGY 

COMNET in uses the following list of terminology as defined in reference to the 
parameter fields available to define objects within a model [Ref. 2 p. 21]: 

• Byte: 8 bits 

• Kilobyte (kB): 1024 bytes 

• Kilobit (kb): 1000 bits 

• Kilobits per second (kbps): 1000 bits per second 

• Megabyte (MB): 1024 Kilobytes = 1,048,576 Bytes 

• Megabits per second: 1,000,0(X) bits per second 

F. STATISTICAL DISTRIBUTIONS AND TABLES 

The major concept which must be understood to model a network within the 
COMNET in application is that the majority of all the characteristics of any of the nodes, 
traffic sources, or applications may be described either by a constant or a statistical 
distribution. The method by which COMNET in picks values from a distribution when 
running a simulation is based on the generation of random numbers. The application 
generates random numbers based on a multiplicative congruential pseudo random number 
generator. A starting seed is used to generate a random number ranging from 0 to 1 and 
the next seed. The new seed produced is used to generate the next random number and 
the next seed. To provide multiple independent random number generators, each 
distribution has the ability to set a stream number. Up to 99 different streams may be used 
within a model. Each stream has its own starting seed which causes it to produce different 
random numbers from any other stream. Weighting functions are then used, which 
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manipulate the random numbers pulled from the uniform (0,1) distribution, to generate 
the desired distribution. The following list displays the distributions which are built into 
the application and the parameters which zu'e used to set the desired shape of the 
distribution. 

• Beta: Shape 1, Shape 2, Min, Max, Stream 

• Erlang: Mean, Shape, Stream 

• Exponential: Mean, Stream 

• Gamma: Mean, Shape, Stream 

• Geometric: Min, Mean, Stream 

• Hyperexponential: Mean 1, Mean 2, Prob Mean 1, Stream 

• Integer: Min, Max, Stream 

• Lognormal: Mean, Standard Deviation, Stream 

• Normal: Mean, Standard Deviation, Stream 

• Poisson: Mean, Stream 

• Triangulzu': Min, Max, Mode, Stream 

• Uniform: Min, Max, Stream 

• Weibull: Shape, Scale, Stream 

Often times when building a model, the same distribution may be needed to set 
parameters on different nodes or traffic sources. The application gives the user the option 
to create user-defined distributions from any of the distributions in the previous list. This 
is accomplished by selecting the User Distribution option from the Define menu. A 
window will then appear as shown in Figure 2.6. Select the Add button and a window will 
appear such as shown in Figure 2.7. A unique name for the distribution must then be 
entered, and a distribution selected and edited to the desired parameters. After a user- 
defined distribution is created, it will appear in the list of distributions which may be 
selected to set the parameters of any object created within the model. 
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Figure 2.6 User Distribution Window 



Figure 2.7 User Defined Distribution Window 

Some data cannot be described in a useful manner using a statistical distribution, 
but can be described using a probability table. COMNET El allows creation of these 
tables through the selection of the Table option from the Define menu which will open a 
window as shown in Figure 2.8. The table must be given a unique name, and the type set 
to either discrete or continuous. Selecting the discrete option implies values entered are 
taken as observation points whose likelihood’s of being chosen are based on the 
probabilities assigned. The continuous option implies the values entered describe the 
envelope of a curve. Values which will be used when running a simulation are then 
interpolated from those entered in the table. For both cases, the probability values entered 
must be in the form of a cumulative distribution function. The last entry in any table must 
have a probability of 1 assigned. To enter values in a table, first select the cell for the 
entry to be made by single clicking on it. Then, in the field above the table enter the value 
which is to be assigned to that cell. Unfortunately the application does not allow entering 
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the probability and its associated value at the same time. Each cell in a table must be 
edited individually. 



Figure 2.8 User defined Tables Window 


G. REPORTS 

The main goal of creating any model is the results which are obtained from 
running a simulation of that model. Reports are produced automatically at the end of 
running a simulation or if the simulation is halted prior to completion of the simulation 
run time. Each replication in a simulation will generate an ASCII file labeled report.1 for 
the first replication, report.2 for the second, and so on. Statistics are only gathered for 
those reports which are selected prior to running the simulation. The number of reports 
and the objects which are included in these reports will affect the simulation run time. A 
greater number of reports requires more processing which will increase the actual length 
of time necessary to run a simulation. Reports are viewed at the end of a simulation by 
selecting the Browse Reports option from the Report menu. A window will appear which 
allows selecting which report to view by entering the replication number. 

Reports are selected from the Define menu which displays a list of all the types of 
objects which may appear in a model. By selecting one of these objects a flyaway menu 
appears which displays the report options available for that object. By selecting a report 
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option a window appears, such as in Figure 2.9, which displays all of the objects within a 
model for which the report may collect data on. The objects are selected by single 
clicking on those desired. Those objects selected will be apparent as they become 
highlighted in blue. If all objects are desired, the All box may be checked. The Show 
Group Node Detail box may be checked if it is desired to see a report on each individual 
node in a computer group. If the box is not selected the computer group is treated as a 
whole. After all of the objects desired are selected click the On box to set the report and 
press the OK button. 





Disk Access Error Counts Reports 
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Figure 2.9 Report Window 


The following lists the types of reports available within the application which may 
be used to gather information concerning packet networks by object type: 

• Node Reports: Processor and Disk Utilization, Input Buffer Use by Port, Input 
Buffer Totals, Output Buffer Use by Port, Output Buffer Totals, Received 
Message Counts, Disk Access Error Counts, and Session Level 

• Link Reports: Channel Utilization, Collision Statistics, and Session Level 

• WAN Cloud Reports: Frame delay by Virtual Circuit, Frame Counts by 
Virtual Circuit, and Access Link Statistics 

• Application Source Reports: Application Run Length 

• Message and Response Source Reports: Message Delay and Packet Delay 
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• Session Source Reports: Message delay, Packet Delay, Setup delay. Session 
Length, and Setup Counts 

• Transport and Command Reports: Message Delay and Packet Delay 

• Setup Command Reports: Message Delay, Packet Delay, Setup Delay, 
Session Length, and Setup Commands 

H. PLOTS AND PERCENTILES 

In addition to the reports available within COMNET HI, the application also 
allows gathering of further data on any type of link defined in a model, all types of traffic 
sources, and WAN cloud virtual circuits and access links. As with any report, the option 
to collect statistics from any of these objects must be selected prior to running a 
simulation. Setting the collection of statistics is accomplished by pressing the Statistics 
button at the bottom center of the window shown in Figure 2.10 for a point-to-point link. 
After pressing the Statistics button, a window will appear, such as Figure 2.11, which 



Figure 2.10 Point-to-Point Detail Window Showing Statistics Button 


displays the statistics which may be gathered for the object. The options for gathering 
statistics are selected with a single click on the option which will highlight that option. By 
then depressing the Edit button, a window will appear such as shown in Figure 2.12. 
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Selecting the Collect stats and Save observations boxes and then pressing the OK button 
will set this option for gathering data during a simulation. 



Figure 2.11 Statistics Options Window 



Figure 2.12 Editing Statistics Options Window 


After the completion of a simulation, the statistics gathered and plots of the data 
gathered may be viewed. This is accomplished by using the Statistics button again to 
bring up the same window as in Figure 2.11. By depressing the View button the statistics 
gathered will be shown. In certain cases, the option will then be presented to plot the data 
saved. By selecting this option a window will appear which contains no plots, but has the 
menu options of File and Plot at the top. By selecting the Plot menu a drop down menu 
will appear giving the option of plotting smooth data, histograms, or percentiles. After 
selecting the desired option the window which appears allows setting the parameters for 
the type of plot selected. 

I. RUNNING A SIMULATION 

COMNET in uses a discrete event simulation methodology when running the 
simulation of a network model. This means the application looks for the first event which 
is to occur in the simulation based on the traffic which is described in the model and 
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executes this event. After completion of this event the simulation then skips to the next 
event which is to occur. This process repeats until the length of time the simulation is set 
to run is completed. 

The first step in running any simulation is to first verify the network model which 
has been built. This is accomplished by selecting the Verify option from the Simulate 
menu. When this option is selected the application performs a logical check of the model 
which has been built. If no errors are detected, the message No verification errors 
detected will appear in the message window at the bottom of the screen. If errors are 
detected, a window will appear displaying all errors in the model which must be corrected 
before a simulation may be run. 

The next step in running a simulation is selecting the parameters which will 
govern how the simulation is to be run. These parameters are set by using the Run 
Parameters option from the Simulate menu which will bring up a window as shown in 
Figure 2.13. The main parameters which are entered via this window are the replication 
length, the warmup length, and the number of replications. Replication length is the 
length of time in seconds that a simulation will run. Warmup length is used to specify the 
time in the simulation when the application will begin to collect data. This feature is 
important as the statistics gathered are based on the entire simulation time after the 
warmup length. At the initiation of a simulation, traffic levels are often low and are 
building up to the steady state level. If a warmup length is not used, the results of reports 
and statistics collected may be erroneously low. The number of replications fields sets the 



Figure 2.13 Simulation Run Parameters Window 
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number of replications for a simulation. This can be used to get multiple shorter runs for 
the collection of data. The Warmup every replication option tells the program to wait the 
warmup length for each replication before collecting data. If a warmup length has been 
specified, but this box is not set, only the first replication will use the warmup length. The 
Reset system every replication box, if set, will clear all traffic from the previous 
replication prior to starting the next. If it is not set, all traffic from the previous replication 
is saved and the next replication begins where the previous left off. 

The application also gives the option to view the movement of packets on screen 
during a simulation. This option is set via the Animate option on the Simulate menu 
which brings up a window as shown in Figure 2.14. The Animate box, if checked, will 
allow the packets to be viewed as they traverse the network.. This option is useful when 
initially running a simulation as a visual check to see if the network is performing as 
expected. However, the Animate option greatly increases the actual simulation run length 
and is not recommended for use when simulation runs are set for gathering data. The Next 
on/off time field allows toggling the animation to either on or off at the simulation time 
set in this field. The Step size field sets the speed at which packets will traverse the 
network topology. The slowest setting is 10, and the fastest is 1000. Any integer value 
between these numbers may be entered. The animate option may be toggled on or off at 
any point when running a simulation. 



Figure 2.14 Simulation Animation Parameters Window 


After the model has been verified, run parameters set, and animate options set, the 
simulation may be run by selecting the Start Simulation option on the Simulate menu. 

The program will then perform another verification of the model and prompt the user to 
save the model if a the model has not been immediately saved prior to starting the 
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simulation. The simulation will run for the length of time specified. Upon completion of 
the simulation, the application will generate any reports which were specified. A 
simulation may be stopped at any time when running by selecting the Halt Simulation 
option. When selected, the simulation will stop and a report will be generated for all data 
gathered up to the point of stopping. 

The program also includes two options which may be used to troubleshoot the 
running of a simulation. The first is the trace option which is invoked by selecting the 
Trace option from the Simulate menu. This brings up a window as shown in Figure 2.15. 
The trace option allows the user to record messages either to a file or to the screen. Either 
option will cause the step-by-step logic followed by the application when running a 
simulation to be recorded which is useful in troubleshooting traffic and application 
sources. If the trace is set to appear on the screen, the user is given two separate options. 
The first option is for display of the message to the screen to appear in a single step 
fashion where the next step will not occur until prompted by the user. The second option 
is to set an amount of time the message will appear on the screen before the application 
goes on to the next step. If the trace to file option is set, a text file is created that records 
each action performed in the simulation. This file may be viewed after completion of the 
simulation. 



Figure 2.15 Simulation Trace Parameters Window 

The other option available is to record the memory usage of the model when 
running a simulation. Large models with many traffic sources and long simulation times 
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tend to cause this application to crash giving the error message that a Modsim II error has 
occurred. The memory usage may be recorded to a text file called memstat.txt by 
selecting the Memory Usage option on the Simulate menu. When this option is selected 
nothing will happen on the screen, but the next simulation run will cause this file to be 
created. The file lists each object and record currently in use by the model, names the 
module within the application to which they belong, and specifies how many of each 
object are currently allocated. The memstat.txt file is useful for determining which 
objects within a simulation use the most memory which may be used to scale the model 
as needed. 
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in. MESSAGE TRAFFIC GENERATION 


A. INTRODUCTION 

The goal of this chapter is to describe the methods available in the COMNET HI 
application to build simple traffic sources and the characteristics which are used to 
describe these sources. The other major goals are to introduce the steps required to buUd a 
simple model of a local area network and to familiarize the user with running a 
simulation. 

B. MESSAGE GENERATING SOURCES 

COMNET in offers several methods for modeling message traffic in a simulation. 
One method is through the building of application sources using global and local 
commands which will be covered in detail in Chapter V. The other method is through the 
use of traffic sources. Traffic sources are simplifications of application commands built 
directly into COMNET HI for ease of generating message traffic. The common thread in 
defining all traffic sources is having the ability to describe the characteristics of the traffic 
being generated by using statistical distributions. The three types of traffic generating 
sources within COMNET HI are message sources, response sources, and session sources. 

1. Message Source 

The message source is a message generator which is capable of sending messages 
to one or more destinations. It is useful at modeling many forms of data transport 
including file transfers and e-mail. A message source may be created using either the 
toolbar or by using the Create menu. Editing of a message source by double clicking on 
the icon will cause the message source window shown in Figure 3.1 to appear. The use of 
the fields to describe the characteristics of the message source are discussed in Section C. 

2. Response Source 

The response source is a message generator used to send message replies upon 
receipt of a message. This source is useful in modeling database queries, e-mail replies. 
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Figure 3.1 Message Source Window 

and any type of message traffic which would be triggered by the receipt of a message. The 
message which is generated by a response source is always sent to the node which 
generated the message which triggered the response source. Response sources may be 
created by either using the toolbar, or the Create menu. Editing of a response source by 
double clicking on the icon will cause the message source window shown in Figure 3.2 to 
appear. The use of the fields to describe the characteristics of the message source are 
discussed in Section C. 

3. Session Source 

The session source is message generator which first sets up a session with another 
node, and then sends the message traffic. It is useful at modeling message sources which 
have a bursty message arrival process as several messages may be transmitted within one 
session. The session source is also used to model connection-oriented traffic. Session 
sources may be created by either using the toolbar, or the Create menu. Editing of a 
session source by double clicking on the icon will cause the message source window 
shown in Figure 3.3 to appear. The use of the fields other than those which apply 
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Figure 3.2 Response Source Window 
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Figure 3.3 Session Source Window 
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specifically to the session source are discussed in Section C. The session source has four 
fields which may be used to describe the characteristics of the source which other traffic 
sources do not have. Explanations of these unique fields are as follows: 

• Messages/session: Specifies the number of messages which will be 
transmitted during one session. This field may be set to a constant or described 
by a statistical distribution. 

• Message lAT: Specifies the interarrival time between messages within one 
session. This field may be set to a constant or described by a statistical 
distribution. 

• Setup packet: Specifies the number of bytes in the setup packet. 

• Confirm packet: Specifies the number of bytes in the session confirmation 
packet. 

C. MESSAGE CHARACTERISTICS 

The characteristics or parameters of all message sources within COMNET HI are 
basically the same. There is some variation based upon the type of message source being 
used. The common features of all sources include specification of a unique name to the 
source; scheduling method, message priority, routing class, selection of a transport 
protocol, setting of a packetizing delay, selection of message size and text, and the choice 
of the traffic destination. 

1. Message Name 

The message name is a unique identifier given to the source for identification 
purposes. This is also the name which will appear in the workspace when building a 
model. 


2. Message Scheduling 

The two methods available for the scheduling of message or session sources of 
traffic are by iteration time or by received message. Response sources may only be 
scheduled by the receipt of a received message. Scheduling message traffic by iteration 
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time means an interarrival time is used to determine the time of the start of the creation of 
one message to the start of the creation of the next message. The interarrival time may be 
set to a fixed value, a user-defined distribution, or any of the distributions supported in 
COMNET HI. The option is also given, when iteration time is specified, to set the 
simulation time when the first and last messages are sent. The first and last arrival may be 
specified in the same manner that the interarrival time may be specified. Received 
message scheduling implies that the traffic source will only become active if triggered by 
the receipt of a message of the required text. When received message scheduling is 
specified, a received message list must be created by the user to trigger the traffic source. 
This is done by pressing the Edit Received Message button on any of the traffic sources. 

A list of all messages defined in the model will appear. By selecting the messages which 
are desired to trigger the source, a list is generated. Received message scheduling also 
allows the option of specifying a delay time which occurs before the response is sent. 

This delay may be modeled by setting a specified time or any statistical distribution 
supported by the application. 

3. Message Priority 

The priority field is used to specify the order of packets in the input and output 
buffers of the various nodes. The priority field may be set to an integer value between 1 
and 99 where larger values have priority over smaller values. Packets with a higher 
priority are placed at the head of the buffer’s queue. Packets of the same priority are 
placed in the queue based on a first-in-first-out (FIFO) algorithm. The priority field does 
not imply priority between several traffic generating sources on the same node [Ref. 2 p. 
112]. The scheduling of different sources on the same node which are in contention is 
done similar to a round-robin fashion. 

4. Message Routing Class 

The routing class is a label which can be applied to any traffic source. A routing 
class called standard is included as a part of any model made and is the default setting 
unless changed. The routing is an additional description of the message which adds 
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parameters which affect the routing of a message when either IGRP, minimum penalty, or 
a user-defined routing tables are specified for a model. The use of routing classes will be 
discussed more in Chapter VIII’s discussion of routing message across a wide area 
network. 


5. Message Transport Protocol 

The transport protocol defines the characteristics of data transfer from the origin 
of the message to its destination across the network. Different protocols may be applied to 
different traffic sources within a model. Currently, COMNET HI has protocol parameters 
for TCP/IP, UDP/IP, NCP/IPX, and NCP/IPX Burst Mode built into the library for use in 
a model. The program also allows the user to define a protocol for use in a model. This 
may be performed by either selecting Transport Protocols in the Define menu or by 
clicking the button next to the transport protocol field in any traffic source. When 
either of these options is performed a window such as the one shown in Figure 3.4 will 
appear. 
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Figure 3.4 Transport Protocol Parameters 

When defining a protocol, a unique name must be set and a routed protocol 
identification selected from the choices given. COMNET HI does not allow the user to 
define the routed protocol identification. These are built into the program, and the user 


28 






























may choose from Appletalk, IP, OSI, source routing, IPX, bridge, and DECnet protocols. 
The packet data bytes field allows setting the maximum packet size. This number is made 
up of both the payload capacity of the packet and the overhead. The packet overhead 
bytes field sets the number of overhead bytes in the creation of a packet. If a method of 
flow control is used, the window size field must have an integer number placed in this 
field and a retransmit time must be specified. Also, if flow control is used, the number of 
bytes of the acknowledgment packet must be set. If no flow control is needed in the 
protocol, the flow control field should be set to none. COMNET in has flow control 
algorithms for fixed window, sliding window, and SNA pacing available within the 
application. 


a. Fixed Window Flow Control 

The originating node creates and transmits packets until the number of 
packets equals the window size. The destination only acknowledges the last packet to 
reach the destination. When the acknowledgment for the last packet is received at the 
origin, another set of packets (#packets = window size) may be created and transmitted. 

b. Sliding Window Flow Control 

The originating node creates and transmits packets until the number of 
packets equals the window size. The destination acknowledges every packet. When the 
acknowledgments for all packets are received at the origin another set of packets 
(#packets = window size) may be created and transmitted. 

c. SNA Pacing Flow Control 

In this mode of flow control, a pacing counter is initialized to the window 
size specified. This counter decrements each time a packet is created, and packet creation 
stops when the counter reaches zero. The destination only acknowledges the first packet 
of the window of packets which is sent. When the acknowledgment is received by the 
originating node, the counter is incremented and another window of packets may be 
created and transmitted. 
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6. Packetizing Delay 

Packetizing delay is the amount of processing time in milliseconds to make a 
packet at the originating node. The COMNET III Users Manual specifies that this delay 
could be used to model transaction processing times at a node vice building detailed 
applications, or to model the transport layer overhead processing [Ref. 2 p. 110]. 

7. Message Size 

Message size may be selected to be in units of either bytes or packets. This option 
is set by setting the message size units field in any of the traffic sources to the desired 
option. The message size calculation has two options available for determining the size of 
the message to be calculated. Any of the statistical distributions supported in COMNET 
III may be used to model the size of the message generated. In addition, if received 
message scheduling is used, the size of the message may be based on the size of the 
message which triggered the traffic source. Only a linear model is available if the option 
is selected, and the size calculation takes the form: 

Message Size = Multiplier * Received Message Size + Offset 

Thus, if the multiplier is set to 1 and the offset to 100, a message of 100 bytes 
greater in length than the message received will be generated. 

8. Message Text 

When a message is created, an arbitrary text label associated with the message is 
also created. This text label can then be used to trigger an application or traffic source at 
the receiving node. Different applications or traffic sources may use the same message 
text. This can often be a very useful feature in simplifying the creation of a model as 
various nodes having different parameters for their traffic’s size and interarrival time may 
be desired to trigger a response source on another node. The message text for these 
applications or traffic sources may all be set the same in order to simplify remembering 
which messages are used to trigger which applications. 
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There are three methods for which the text of the message may be set. The Use 
original message option can be used for applications or traffic sources which were 
scheduled using the received message option. In this case the text of the message which 
triggered the source is set as the text of the message to be generated. The Copy message 
name option is the default setting which uses the name of the source generating the traffic 
as the text. The final option. Set message text, allows the user to explicitly set the 
message text by typing in the desired text or choosing the text of any traffic source that 
has been created in a model. 

9. Message Destination 

The final attribute of all message sources is the destination field. The option of 
setting a destination is available to all traffic sources except the response source where, 
by default, the destination will be to the node that triggered the source generating the 
packet. The four options available for defining message destinations are to a random 
neighbor, random list, weighted list or a multicast list. 

a. Random Neighbor 

When the random neighbor option is chosen, COMNET III builds a list of 
all other nodes which are one hop away from the node generating the packet. These nodes 
are each given an equal probability of receiving the packet and picked randomly as the 
destination when a packet is created. 

b. Random List 

A random list allows the user to select a random group of nodes which 
will each be assigned an equal probability of being randomly selected as the destination. 
The list of possible nodes is defined by the user by selecting the Edit Destination List 
button. This will bring up a list of all nodes in the model from which the nodes desired 
may be selected. 
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c. Weighted List 

The weighted list is very similar to the random list with exception that the 
probability of a given node being chosen as the destination may be weighted as needed to 
model where the traffic will go. Building the list for the destination is done in the same 
manner as in building the random list. There is, however, an additional field for setting 
the probability for a message being selected to go to a given node. This probability may 
be set by either double clicking on a given destination in the list or by selecting a 
destination with a single click and then depressing the edit button. In both cases a window 
will appear which allows setting the probability. The most important part of building this 
list and setting the probability values is that the sum of the probabilities of all nodes in the 
list must be exactly equal to one. If this is not true, an error message will appear when the 
model is verified prior to running a simulation. 

d. Multicast List 

The multicast list is used to send a message to more than one destination at 
a single time. The list creation is done in the same manner as that of a random list. A 
restriction placed on this option is that it is only available for use with a message source. 
The COMNET III Users Manual states that ho flow control is used when generating 
packets to a multicast list irrespective of the transport protocol chosen to deliver the 
message [Ref. 2 p. 65]. In working with the program, however, this was not found to be 
true. To use this type of list the transport protocol which is selected must not use any flow 
control or attempt of packet retransmission. The only protocol which is directly built into 
the application which has this feature is UDP/IP. 

D. MODELING OF MESSAGE TRAFFIC 

All traffic sources within COMNET HI follow a similar logic in the creation of 
message traffic when running a simulation. The following list describes the key steps 
which occur in the simulation [Ref. 2 p. 59]: 
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1. A message of the required size, priority, routing class, transport protocol, and 
packetizing delay is created. 

2. The message text is set. 

3. The destination of the message is set. In the case of the response source, the 
message destination is restricted to only being to the node which triggered the 
response source. 

4. If required acknowledgments (ACK) packets from the flow control windowing 
have been received, a packet is created. If ACK packets have not been 
received, the packet creation will not occur until receipt of the outstanding 
ACK packets. The first packet of any message will never have to wait for an 
ACK packet. 

5. A routing decision is then made to determine the buffer to which the packet 
has to be sent. The node which is generating the packets is then made busy by 
the packet switching delay defined for the node. If the routing algorithm 
cannot find a route, then the packet is blocked. The packet may then be 
optionally retried depending on the characteristics of the transport protocol. 

6. If no space is available in the output buffer, the packet is dropped. If the 
transport protocol specifies retries, the retry time elapses and the packet 
creation is attempted again. 

7. The packet is then transported across each link to arrive at its destination node. 
Again, if a block occurs at any point the packet is dropped and retry occurs 
depending on the transport protocol used. 

8. When the packet reaches its destination, if flow control is in operation, and if 
receipt of the packet requires an acknowledgment, then an ACK packet will be 
created at the destination and routed back to the origin using the same routing 
class, transport protocol, and routing algorithm as the received packet. 

This previous list of steps is valid for all traffic sources, but the following logic is 
applied prior to the creation of the message packets when setting up a session 
[Ref 2 p. 54, 55]: 
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1. The session is created at the node where the session source is located, and the 
destination for the session is made. 

2. A session setup packet is created. Unlike message packets, the setup packet 
does not incur a packetizing delay. It does, however, incur a packet processing 
delay which is defined on the node creating the packet. 

3. A routing decision is then made and the packet switched to the appropriate 
output buffer. 

4. Session packets may be blocked in several manners including insufficient 
space in the output buffer or reaching the session limit for a node or a link. 

5. When the setup packet reaches the destination node, the destination creates a 
confirmation packet following the reverse route of the setup packet. 

6. On receipt of the confirmation packet at the originating node, message packets 
may then begin to be created. 

When running a simulation, there may be more than one application or traffic 
source scheduled or in progress of generating packets at the same time on a node. Each 
node maintains a list of applications and message sources currently scheduled. The logic 
in deciding who gets to send the next packet is that the application or traffic source at the 
top of the list is selected and a packet is created. After execution, the application or traffic 
source is then placed at the bottom of the list and the next application runs. This 
multitasking of applications or traffic sources is similar to a round robin tasking with the 
exception that a message which is waiting for flow control authorization will not block 
another application. 

E. PROBLEM STATEMENT 

A portion of a mythical company’s LAN consists of two networks. Each network 
services one department. One network is set up in accordance with the IEEE 802.3 
CSMA/CD lOBaseT Ethernet network. The other network is set up in accordance with 
the IEEE 802.5 16Mbps Token Ring standard. The two networks are connected together 
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via a Proteon DNX300, VI 2.0 router. The ethemet LAN supports 10 computers, one of 
which is designated as the e-mail server for both departments. The token ring LAN also 
supports 10 computers where one is designated as the file server for both departments. 

The company is currently considering the addition of personnel to both 
departments. However, a concern is that the current network configuration will not be 
able to support additional personnel as the company currently has no method of 
measuring network utilization or delay. The company wishes to estimate these current 
baseline levels prior to hiring any new personnel. Also, complaints have recently been 
made by the employees in both departments concerning network delays when trying to 
receive a file from the file server. 

An estimate of the common traffic which flows across the two LANs indicates 
that the majority of traffic is from e-mail, file transfers from various applications, and a 
LAN voice mail system which allows supervisors to send voice mail message to 
personnel in there own department over the LAN. Interviews with the employees in each 
department, and estimates of the common size of messages sent over the LAN were used 
to statistically describe the message characteristics. 

E-mail is used by all personnel in both departments. The interview of all 
personnel indicated the sending of an email message occurs at an average interarrival rate 
which can be described by an exponential distribution which has a mean of 900 seconds. 
The size of email messages can be described by a uniform distribution where the size is 
evenly dispersed over the range of 500 to 2000 bytes. All email messages are sent to the 
email server located on the ethemet LAN where they are saved in each employee’s 
account. In order to read the email the employee must send a request to the e-mail server 
for downloading the messages to their computer. The interarrival time for the checking of 
email can be described by a Poisson distribution with a mean of 900 seconds. Each 
request has a message size set at 60 bytes. Upon receipt of a request to download e-mail, 
the e-mail server reads the employee’s file and transmits the messages to the employee’s 
computer. The amount of time necessary to read the file and to process the messages on 
the server can be described by a uniform distribution which ranges from 3 to 5 seconds. 
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The size of the e-mail messages transmitted by the server may be described by a Normal 
distribution which has a mean of 40000 bytes and a standard deviation of 10000 bytes. 

There are eight employees in each department who each have their own computer 
and also generate traffic due to requests for files to the file server. The file requests can be 
described by an exponential distribution with a mean of 900 seconds. The size of the file 
requests vary in accordance with a uniform distribution which ranges from 10 to 20 bytes 
in length. All file requests are sent exclusively to the file server located on the token ring 
network. Upon receipt of a file request, the file server reads the file and transmits it to the 
computer which made the request. There is little delay in this process. The size of the 
files to be transferred may be described by a Normal distribution which has a mean of 
100000 bytes and a standard deviation of 25000 bytes. 

The LAN voice mail application is used solely by the supervisors of each 
department. The supervisors generally send voice mail only to personnel within their own 
department. This application first sets up a session with the computer belonging to the 
person the message is to be sent to. Upon receipt of the acknowledgment that a session 
has been set up, the voice mail message is sent. The size of these messages can be 
characterized by a Normal distribution with a mean of 50000 bytes and a standard 
deviation of 1200 bytes. The interarrival time of these message can also be described by a 
normal distribution with a mean of 1000 seconds and a standard deviation of 10 seconds. 
As a final note, all of the message sources which are to be defined use TCP/IP as the 
transport protocol and have been estimated at having a packetizing delay of 0.01 
milliseconds. 

F. BUILDING THE NETWORK MODEL 

The Steps to build the model are presented in a method such that the pieces of the 
model are constructed object-by-object. In general, models are normally constructed by 
first constructing the network topology. This implies constructing all computers, routers, 
switches, and links through which messages are created and transported. The second step 
consists of defining the traffic sources which will generate the load on the network. Upon 
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completion of building the network model, the network topology should appear similar to 
the topology shown in Figure 3.5. 



1. Creating the Network Topology 

The following defines the steps necessary to create the nodes and links which will 
be used in the model: 

a) Create a collision link and a token passing link in the work area. 

b) Edit the fields of the collision link detail window to those values shown in the 
following list. Figure 3.6 depicts the link detail window upon completion of this step. 

• Name; ETHERNET 

• Type: CSMA/CD 

• Parameters: 802.3 CSMA/CD 1 OB ASET 

c) Edit the fields of the token passing link detail window to those values shown in the 
following list. 

• Name: TOKEN RING 

• Type: Token passing 

• Parameters: 802.5 16 Mbps 
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Figure 3.6 Ethernet Link Detail Window 


d) Create a router node and place it between the two links in the work area. Connect the 
router node to both links using either connection tool on the toolbar. Edit the fields of 
the node detail window for this node to those of the following list and shown in 
Figure 3.7. 

• Name: ROUTER 

• Type: Router 

• Parameters: Proteon DNX 300, VI 2.0 



Figure 3.7 Router Node Detail Window 

e) Create four computer and communication (C&C) nodes. Edit the fields of the node 
detail window for each node to the values shown in Table 3.1. Attach each node to the 
link specified in Table 3.1. 
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Name 

Type 

Parameters 

Link 

ETHER PC 1 

C&C Node 

Default 

ETHERNET 

E-MAIL SERVER 

C&C Node 

Default 

ETHERNET 

TRPC 1 

C&C Node 

Default 

TOKEN RING 

FILE SERVER 

C&C Node 

Default 

TOKEN RING 


Table 3.1 Computer and Communication Node Detail Values 


f) Choose the Node Parameters/Computer Group option from the Define menu. In the 
first computer group parameters window which appears press the Add button. In the 
second computer group parameters window which appears, edit only the following 
fields: 

• Name: PC 

• Number in group: 8 

g) Create two computer group nodes in the work area. Edit the fields of the node detail 
window for each node to the values shown in Table 3.2. Attach each node to the link 
specified in Table 3.2. 


Name 

Type 

Parameters 

Link 

ETHER PC 2 - 9 

Computer Group 

PC 

ETHERNET 

TR PC 2 -9 

Computer Group 

PC 

TOKEN RING 


Table 3.2 Computer Group Node Detail Values 


2. Creating the E-mail Message Source 

The e-mail message source is used to model the transport of e-mail message from 
nodes in the network to the e-mail server. 

a) Create a message source and attach it to the ETHER PC 1 node. 

b) Edit the message source such that the fields of the message source window are set to 
the values of the following list. Figure 3.8 depicts the message source window upon 
completion of this step. 

• Name: E-MAIL 

• Schedule by: Iteration time 

• Interarrival: Set to an exponential distribution with a mean of 900 seconds. 
The stream value may be set to any integer value from 0 to 99. 
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• Priority: 1 

• Routing class: Standard 

• Transport protocol: TCP/IP - Microsoft 

• Packetize: 0.01 milliseconds 

• Message size calculation: Probability distribution 

• Probability distribution: Set to a uniform distribution with a minimum of 500 
bytes and a maximum of 2000 bytes. The stream value may be set to any 
integer value from 0 to 99. 

• Message text option: Copy message name 

• Destination type: Set to weighted list. Create a list containing only the E- 
MAIL SERVER node. 



Iteration time 


Exp(900.0) 


TCP/IP-Mi«)^ 




Probability distribution 


Uni(500.0.2000.0) 


Weighted list 




Message Source 


Figure 3.8 E-MAIL Message Source 


c) Create three clones of the E-MAIL message source. It is important to clone the 
message source vice copy and pasting. Copying a message source will cause the 
destination information to be lost in the copies made whereas cloning will keep the 
destination information. 

d) Attach one copy of the E-MAIL message source to the ETHER PC 2 - 9, TR PC 1, 
and TR PC 2-9 nodes. 


40 






















































3. Creating the E-mail Checking Message Source 

The e-mail check message source is used to model periodic checks by users on the 
network to the e-mail server to download their mail. 

a) Create a message source and attach it to the ETHER PC 1 node. 

b) Edit the message source such that the fields of the message source window are set to 
the values of the following list. Figure 3.9 depicts the message source window upon 
completion of this step. 

• Name; E-MAIL CHECK 

• Schedule by: Iteration time 

• Interarrival: Set to a Poisson distribution with a mean of 900 seconds. The 
stream value may be set to any integer value from 0 to 99. 

• Priority: 1 

• Routing class: Standard 

• Transport protocol: TCP/IP - Microsoft 

• Packetize; 0.01 milliseconds 

• Message size calculation: Probability distribution 

• Probability distribution: Set to a constant value of 60 bytes. 

• Message text option: Copy message name 

• Destination type: Set to weighted list. Create a list containing only the E- 
MAIL SERVER node. 



Figure 3.9 E-MAIL CHECK Message Source 
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c) Create three clones of the E-MAIL CHECK message source. 

d) Attach one copy of the E-MAIL message source to the ETHER PC 2 - 9, TR PC 1, 
and TR PC 2 - 9 nodes. 


4. Creating the E-mail Response Source 

The e-mail response source is used to model the downloading and transport of e- 
mail traffic from the e-mail server. 

a) Create a response source and attach it to the E-MAIL SERVER node. 

b) Edit the fields of the response source window to the values shown in the following list 
and depicted in Figure 3.10. 



Figure 3.10 E-MAIL RESP Response Source 


• Name: E-MAIL RESP 

• Edit Received Message button: Press and create a list such that receipt of one 
message with the text E-MAIL CHECK will trigger the source. 

• Received message delay: Set to a uniform distribution with a minimum of 3 
seconds and a maximum of 5 seconds. The stream value may be set to any 
integer from 0 to 99. 

• Priority: 1 

• Routing class: Standard 
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• Transport protocol; TCP/IP - Microsoft 

• Packetize: 0.01 milliseconds 

• Message size calculation: Probability distribution 

• Probability distribution: Set to a normal distribution with a mean of 40000 
bytes and a standard deviation of 10000 bytes. The stream value may be set to 
any integer from 0 to 99. 

• Message text option: Use original message 

5. Creating the File Request Message Source 

The file request message source is used to model requests to the file server to 
download files. 

a) Create a message source and attach it to the ETHER PC 2 - 9 node. 

b) Edit the message source such that the fields of the message source window are set to 
the values of the following list. Figure 3.11 depicts the message source window upon 
completion of this step. 



Iteration time 


ExpOOO.O) 


|TCP/IP - Mic^i 


none 


Probability disbibution 


Uro(10.0^0.0) 


Random list 


Message Source 


Figure 3.11 FILE REQ Message Source 


• Name; FILE REQ 

• Schedule by: Iteration time 
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• Interarrival: Set to an exponential distribution with a mean of 900 seconds. 
The stream value may be set to any integer value from 0 to 99. 

• Priority: 1 

• Routing class: Standard 

• Transport protocol: TCP/IP - Microsoft 

• Packetize: 0.01 milliseconds 

• Message size calculation: Probability distribution 

• Probability distribution: Set to a uniform distribution with a minimum of 10 
bytes and a maximum of 20 bytes. The stream value may be set to any integer 
value from 0 to 99. 

• Message text option: Copy message name 

• Destination type: Set to random list. Create a list containing only the FILE 
SERVER node. 


c) Create one clone of the FILE REQ message source and attach the clone to the 
TR PC 2- 9 node. 


6. Creating the File Server Response Source 

The response source which will be connected to the file server is used to model 
the transmission of files across the network upon receipt of a file request. 

a) Create a response source and attach it to the FILE SERVER node. 

b) Edit the fields of the response source window to the values shown in the following list 
and depicted in Figure 3.12. 

• Name: FILE RESP 

• Edit Received Message button: Press and create a list such that receipt of one 
message with the text FILE REQ will trigger the source. 

• Priority; 1 

• Routing class: Standard 

• Transport protocol: TCP/IP - Microsoft 

• Packetize: 0.01 milliseconds 

• Message size calculation: Probability distribution 

• Probability distribution: Set to a normal distribution with a mean of 100000 
bytes and a standard deviation of 25000 bytes. The stream value may be set to 
any integer from 0 to 99. 

• Message text option; Use original message 
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Standard 


TCP/IP-Micf 


\iMm 


Response Source 






Figure 3.12 FILE RESP Response Source 


7. Creating the LAN VOICE Session Source 

The LAN VOICE session source is used to model the transmission of voice mail 
across the network. 


a) Create a session source and attach it to the ETHER PC 1 node. 

b) Edit the fields in the session source window to those of the following list and which 
are depicted in Figure 3.13: 




Name: LAN VOICE 
Schedule by: Iteration time 

Interarrival: Set to a normal distribution with a mean of 1000 seconds and a 
standard deviation of 10 seconds. The stream value may be set to any integer 
value from 0 to 99. 

Priority: 1 

Routing class: Standard 

Transport protocol: TCP/IP - Microsoft 

Packetize: 0.01 milliseconds 

Messages/session: 1 

Message lAT: none 

Setup packet: 40 bytes 

Confirm packet: 40 bytes 

Message size: Set to a normal distribution with a mean of 50000 bytes and a 
standard deviation of 1200 bytes. The stream value may be set to any integer 
value from 0 to 99. 
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Message text option: Copy message name 

Destination type: Set to random list and create a list containing only the 
ETHER PC 2 - 9 node. 



Figure 3.13 LAN VOICE Session Source 

c) Create a copy of the LAN VOICE session source and attach it to the TR PC 1 node. 
Edit the destination list of this copy so that traffic from this source only goes to the 
TR PC 2 - 9 node. 

d) The model is now complete. Use the Verify Model option from the Simulate menu to 
check the model. Fix any errors which may have occurred while building the model 
and save the model. 

G. SIMULATION AND RESULTS 

The simulation used to analyze the problem was set to run for 3600 seconds to 
simulate the traffic which would occur in one hour. A warmup length of 120 seconds was 
used to allow message traffic to build up prior to beginning to collect statistics. For this 
simulation only one replication was be run. Prior to running the simulation the reports 
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which will collect statistics need to be set. The following reports were used for this 
simulation: 

• Link Reports: Channel Utilization and Collision Statistics for all links. 

• Node Reports: Received Message Count for all nodes. 

• Message and Response Reports: Message Delay for all nodes. 

• Session Source Reports: Message Delay for all nodes. 

After running the simulation, the results may be viewed by selecting the Browse 
Reports option on the Report menu. The following shows a portion of the report which is 
generated by COMNET IQ after the completion of a simulation. 


LINK DELAYS AND UTILIZATION 
REPLICATION 1 FROM 120.0 TO 3720.0 SECONDS 


FRAMES TRANSMISSION DELAY (MS) % 


LINK 

DELIVERED 

RESENT 

AVERAGE 

STD DEV 

MAXIMUM 

UTIL 

ETHERNET 

9483 

0 

0.763 

0.883 

31.002 

0.11 

TOKEN RING 

7386 

0 

0.381 

0.363 

0.763 

0.08 


ORIGIN / MSG SRC NAME: MESSAGES MESSAGE DELAY (MILLISECONDS) 

DESTINATION LIST ASSEMBLED AVERAGE STD DEV MAXIMUM 


E-MAIL SERVER / src E-MAIL RESP: 


ECHO 

73 

42.503 

11.426 

67.976 

FILE SERVER / src FILE RESP: 
ECHO 

31 

80186.450 

82589.636 

434398.450 


LINK NAME ETHERNET 


ACCESS PROTOCOL 
COLLISION EPISODES 
COLLIDED FRAMES 


CSMA/CD 

4830 

9665 


NBR OF TRIES TO RESOLVE 
AVERAGE 

STANDARD DEVIATION 
MAXIMUM 


1.63 

0.96 

9 


NBR OF DEFERRALS 


3161 


DEFERRAL DELAY (MS) 
AVERAGE 

STANDARD DEVIATION 
MAXIMUM 


0.62 

0.52 

1.22 


DEFERRAL QUEUE SIZE (FRAMES) 

AVERAGE 0.00 
STANDARD DEVIATION 0.02 
MAXIMUM 2 


MULTIPLE COLLISION EPISODES 

NBR EPISODES 5 
AVG PER EPISODE 3.00 
MAX PER EPISODE 3 
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The results show that neither network is utilized to a great extent and collisions on 
the ethemet network are not severe. The interesting note is that the simulation does show 
that long delays do occur when requesting files from the file server, but that the delay is 
not consistent as the standard deviation is greater than the average delay. One possibility 
to remedy this situation would be to add another file server to the ethemet network which 
would serve only users on that network. 

The final question to be asked is “How accurate is this simulation ?” The answer 
is probably not as good as needed to make any major changes to the network, but it 
provides a decent first look at estimating the performance of the network. The model 
which was developed in this chapter was not based on any actual network, but was for 
demonstration purposes only to give a first look at building a model within COMNET El 
with the emphasis on familiarization with the tools available to simulate network traffic. 
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IV. THE COMPUTER AND COMMUNICATION NODE 


A. INTRODUCTION 

The goal of this chapter is to familiarize users with the computer and 
communications node (C&C node) object and the characteristics of this object. 

The computer group node will also be covered as it is very similar to the computer and 
communication node, and the port object will also be covered. 

B. COMPUTER AND COMMUNICATIONS NODE THEORY 

The computer and communication (C&C) node is a generic node that is used for 
the modeling of end systems such as computers, printers, facsimile machines, or any 
general piece of network hardware [Ref. 2 p. 122]. The C&C node may act as the origin 
or destination for message traffic, run applications, or act as a switching point within a 
network. Any type of link, and as many links as needed, may connect to this type of node 
for modeling a network. The C&C node is represented in a model as having the following 
attributes [Ref. 2 p. 122]: 


• Input buffers for each link connected to the node for accepting packets 
transmitted to the node. 

• A processor for command execution and packet processing. 

• Output buffers for each link connected to the node through which the node 
may route packets. 

• Local disk storage for modeling disk read and write processes. 

• A command list which defines how application commands are to be executed 
on the node. 

• A pending application list of all applications and traffic sources currently 
scheduled to run. 

• A prototype application list of all available applications and traffic sources for 
the node. 

• A received message list for saving received messages used to trigger an 
application or traffic source. 

• A list of files which reside in storage on the local disk. 
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1. Computer and Communications Node Processor Scheduling 

The processor in the computer and communications node is used for the 
processing of application and traffic sources, and for the processing of packets which the 
node receives. When the processor becomes idle a choice must be made as to whether to 
run an application from the pending application list or to process a packet waiting in an 
input buffer queue. The choice is made by comparing the wait times of the packet at the 
head of each input buffer to the wait time of the application at the head of the pending 
application list. The packet or application which has the longest wait time is chosen to 
execute next. 

Each node maintains a list of all applications and traffic sources which may run on 
that node. When scheduled to run in an application, a prototype of the application or 
traffic source is created and added to the pending application list. The list is maintained 
such that the application or traffic source which has waited the longest will be at the top 
of the list. When the choice is made for the node to process a packet or run an 
application, normally the application at the top of the pending application list is chosen. 
The exception to the rule occurs when the application at the top of the list is waiting for 
flow control clearance to create packets or for a file to be unlocked for a read command. 
These exceptions make the scheduling of applications on the list be described as a semi 
round robin process. 

The node processor is not modeled by a unique value such as the processor speed. 
Instead, various attributes of the node are set to model the use of the processor in 
performing different functions. Parameters for a local hard disk are used to describe the 
processing required when reading or writing a file. Packet processing attributes model 
the manner in which the processor on the node processes packets. A processing time per 
cycle attribute is used to describe the manner of executing processing commands in an 
application. 

In the scheduling of all these types of functions the option is given to the user to 
model the node as a single function computer which completes the entirety of one task 
before going on to the next or as a multitasking type computer which uses time slicing to 
alternate between various applications. 
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a. No Time Slice Execution 

A node in this mode of operation will pick an application to run or a 
packet to process as in the manner previously described. The processor will then execute 
every command within an application or complete the processing of a packet. When the 
present task is completed a scheduling decision will be made for the next task to 
accomplish. The exception to this rule occurs in the generation of messages on a node by 
either an application or a traffic source. When a message is created on a node, it must 
have flow control clearance to generate the packets to be sent across the network. Instead 
of waiting for flow control to complete the sending of all packets of one message at one 
time, the processor will either process incoming packets or generate packets for another 
application in the pending application list. In this manner packets coming into the node 
will be interleaved with those packets being created by the node. 

b. Time Slice Execution 

When time slice execution is chosen the method of choosing which 
application to run or packet to process does not change. The difference is that each 
process is given a portion of the processor time, and at the end of this time the application 
is interrupted and put at the bottom of the pending application list. When the application 
is rescheduled later the interrupted command resumes where it last left off. 

2. Buffer Processing 

Buffer processing is used to model the delays within the input/output ports of the 
simulated computer due to the processing of packets at the port buffers. This processing 
delay is not a portion of the main processor simulated on a C&C node. A packet arrives at 
a node when all of the frames which make up the packet reach the node. The packet is 
then attempted to be placed into the input buffer of the node. If either the port input 
buffer is full or the total buffer space for the entire C&C node is full the packet is 
blocked. If the packet is accepted into the port buffer, its position in the buffer’s queue is 
based on decreasing priority and first-in-first-out order. The packet will then incur the 


51 


buffer processing delay. After incurring this delay, the packet is then made available for 
switching by the main C&C node processor. 

C. COMPUTER AND COMMUNICATION NODE PARAMETERS 

The computer and communications node may be created from either the toolbar or 
by selecting the Nodes/Computer and Communications option from the Create menu. 
After creation of the node, editing it will bring up a window as shown in Figure 4.1. The 



Figure 4.1 Computer and Communications Node Dialog Box 


creation of any type of node will bring up this window. Each node created should be 
assigned a unique name to be able to identify it in a model. The window also allows 
entering information concerning the time to failure and time to repair which may be 
modeled as a constant or using a statistical distribution. The current state of the node may 
be set to either up or down, and a simulation time to toggle the state of the node from its 
current setting may be entered. The Command button allows for the generation of 
application commands which will be available only to the node they are created on. The 
parameter set which will define the attributes of the node may be set by either pressing 
the button with double dots on it at the end of the parameter field or by defining a 
computer and communications node parameter set from the define menu. When either of 
these option is selected a window will appear listing all of the parameter sets available for 
the node. By depressing the Add button in this window, the node parameter window as 


52 
































shown in Figure 4.2 will appear. Discussion of the parameters which may be entered are 
covered in the following subsections. 



Figure 4.2 Computer and Communication Node Parameter Window 


1. Parameter Set Name 

A unique name should be assigned to any parameter set made. Once a parameter 
set is entered into a model it is available for use on all subsequent C&C nodes created. 
The parameter set on subsequent nodes is selected using the name entered in this field. 

2. Source or Sink Only 

A check in this box designates that the node for which the parameter set is apphed 
may only be used to run applications or for the receipt or generation of message traffic. 
The node may not be used to switch traffic. 
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3. Application Processing 

The two fields of Processing/cycle and Time slice set the parameters which 
describe the basic operation in modeling a computer. They are also two of the most 
difficult parameters to model. According to Mr. Kit Jones, a CACI Products Inc. test 
engineer, “COMNET III does not provide a robust capability for the modeling of 
computers using the C&C node.” 

The Processing/cycle field may be set as a constant or by a statistical distribution 
and is entered in units of microseconds. This parameter setting this field is used only for 
modeling the speed at which processing commands in an application occur in a 
simulation. The choice of scaling was used as a processing command is entered in units 
of cycles. Thus, the actual amount of time a processing command will execute on a node 
is the processing/cycle field multiplied by the number of cycles to execute in a process. 

The Time slice field may be set to none to model a computer for which 
multitasking of applications is not desired, or to a constant or any statistical distribution 
to model computers that do multitask. Most operating systems perform the time slicing of 
applications based on the number of applications currently running on a computer at a 
given time and the state of processes which are running. COMNET m currently does not 
support scheduling of applications in this manner. Correspondence with CACI Products 
Inc., Mr. Kit Jones, indicated that using a short time slice is the best method to 
approximate a multitasking environment eis no process would wait an excessive amount 
of time to be serviced, and all processes would be serviced in a round-robin order. 

4. Packet Processing 

Packet processing is a delay applied to each packet as it is switched through a 
node which is used to model the processing time which would occur by the main node 
processor. This delay is in addition to the buffer processor delay which occurs in the port 
buffer. Packets created on a node first undergo a packetizing delay from the generating 
source to model the time needed to create a packet. The packet processing delay then 
occurs to model the processing delay of switching the packet to the desired output buffer. 
The packet finally undergoes the buffer processing delay. The order of these delays is 
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reversed for an incoming packet, packet processing may be modeled in three different 
ways in the model. 

a. Packet Processing by Routed Protocol Identification 

The packet processing in this mode is modeled based on the routed 
protocol identification of the packet being created or received. These values are set by 
pressing the Edit Times... button next to the packet processing as shown in Figure 4.2 
which will a list of packet processing times to appear in a window such as shown in 
Figure 4.3. In this window press the Add button and the packet processing time window 
shown in Figure 4.4 will appear. In this window select the desired routed protocol 
identification from the drop down list. The Processing/packet field is set in units of 
milliseconds and may be set to a constant value or modeled using a statistical distribution. 
When all values are entered depress the OK button as shown in Figure 4.4, and then the 
Done button as shown in Figure 4.3 to set the entered values. 



Figure 4.3 Packet Processing Times List Window 



Figure 4.4 Packet Processing Times Editing Window 
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b. Packet Processing by Packet Size 

A device may behave such that the switching of larger packets takes longer 
than the switching of a shorter packet. The Processing/Kbytes field allows for the 
modeling of this behavior using the linear relationship [Ref. 2 p. 130]: 

Switching Time = Ax + B 

• A = processing/Kbytes 

• X = packet size in kilobytes 

• B = the processing/packet. 

The Processing/Kbytes field may be set to a constant or modeled using any statistical 
distribution. 


c. Packet Processing for Setup Packets 

Session sources and setup commands may be used to establish connection 
oriented routing across a network. All subsequent data packets which follow the setup 
packet will follow the same route as the setup packet. In establishing the route, the setup 
packet may be modeled as having a longer delay. The Processing/setup field only affects 
setup packets and may be used to model a longer delay at each node in setting up a route. 
The field may be modeled as a constant or any statistical distribution and is scaled in 
units of milliseconds. 

5. Port Processing 

The processing time of a packet in the port buffers may vary as a function of the 
routed protocol identification and the type of link the node is connected to. When a 
packet arrives at a node the model will first look for any special case processing times. If 
no match is found, the default value is used. 

The port processing times are entered by selecting the Edit Times... button next to 
the port processing field as shown in Figure 4.2 which will cause a window such as 
shown in Figure 4.5 to appear which contains the list of all special port processing times 
entered. By pressing the Add button in this window the port processing editing window 
will appear as shown in Figure 4.6. In this window select the desired type of link and 
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routed protocol identification from the drop down list. The port input and output delays 
may only be entered as constant values and are scaled in units of milliseconds. When all 
values have been entered, press the OK button as shown in Figure 4.6 and then the Done 
button as shown in Figure 4.5 to set the port processing times for the model. 



Figure 4.5 Special Port Processing Times Window 



Figure 4.6 Port Processing Times Editing Window 


The port processing default input and output delays are set in the default times 
field. These values may be set only as constants in units of milliseconds. The total input 
and output buffer size for the entire node are set in the buffer max field in units of bytes. 
These values are the maximum allowable buffer usage across all ports connected to the 
node. The individual port buffers are set by editing the ports, and will be discussed further 
in Section E of this chapter. 
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6. Disk Storage 

The fields which affect disk storage are used to model a local hard drive on the 
node and the processing which occurs in using this disk. If any read or write conunands 
are used in an application on the node these fields must be set. The Disk field sets the size 
of the hard drive to be modeled in units of megabytes. The Sector field sets the size of the 
sectors on the hard drive in units if kilobytes. The Xfer field sets the amount of time 
requires to read one sector of the disk in units of microseconds and may be modeled as a 
constant or using a statistical distribution. The Seek field sets the amount of time needed 
for the disk to find a file in a sector in units of microseconds and may also be modeled as 
either a constant or using a statistical distribution. 

7. File List 

The file list is a list of files that are to be created on the hard drive prior to the 
beginning of a simulation. All nodes have a file created called GENERAL STORAGE at 
the beginning of every simulation. This file may be used to read or write an arbitrary set 
of bytes to or from the hard disk without the necessity of modeling a complete file 
structure. Files may be created in the file list by pressing the Add button as shown in 
Figure 4.2 which will cause a file detail window to appear as shown in Figure 4.7. In this 
window a unique file name must be entered, the file size in bytes set, and the option is 
given to make the file read only. When all entries are made, press the OAT button. 



Figure 4.7 File Detail Window 


58 












D. COMPUTER GROUP NODES 

While modeling a network, it is common that several nodes will have the same 
parameters and the same traffic generation patterns. The computer group node may be 
used to model several computers in this instance and will reduce the clutter in the work 
area. When running a simulation, each computer defined in the group will be created as 
an instance of that node. Any application or traffic source connected to the node will be 
modeled as available on each computer instance. Messages which are destined for the 
computer group will be parsed out evenly between all computer instances in the group. 
The computer group node is essentially the same as a computer and communications node 
with the following exception. It, by default, may only be used as a source or sink for the 
generation or receipt of message traffic. Also, it may be connected to only one of the 
multi-access type links in a model and may never be connected to a point-to-point type 
link. 

Computer group nodes may be created from either the toolb^ or the Create menu. 
When editing the computer group the computer group parameter window will appear 
such as shown in Figure 4.8. All of the fields for the computer group node parameter sets 
are exactly the same as for the computer and communication node with one exception. 
The computer group node has a Number-in-group field which may be set to an integer 
value to set the total number of computers this node is to model. 

E. PORTS 

Ports are the arcs or lines created in a model which are used to connect the various 
nodes to the various types of links. Ports may be created by using either of the connection 
tools on the toolbar. Connections are made by first selecting a connection tool from the 
toolbar. After a selection is made, single click on the node for which the port is to be 
created. Then drag the mouse to the link the node is to be created on and single click 
again. If the connection is a logical connection, the port will be made. If the connection is 
not logical, such as connecting a node to a node, nothing will happen. 

Ports may be thought of as modeling a portion of the network interface cards 
within all types of nodes. They have the characteristics of having buffer capacity and are 
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Figure 4.8 Computer Group Parameters Window 


used in modeling the port processing delays. Editing of the port is accomplished by either 
double clicking on the arc or by selecting the arc and then choosing the detail option from 
the edit menu. When this is done the port parameter window as shown in Figure 4.9 will 
appear. The buffer capacity for both the input and output buffers is the number of bytes 
available to hold packets in the port while waiting to be switched on a node. The delay is 



Figure 4.9 Port Parameter Window 
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by default set to the default port processing time of the node it is attached to or may be 
edited in this window. The Line Card Identification field is only applicable when the port 
is attached to a router node. This field is used to differentiate between different ports on 
the router node for simulated switching across a router bus. The packet routing penalty 
may be defined using a penalty table. This feature will be discussed in more detail in 
Chapter VIH. 

F. PROBLEM STATEMENT 

The Naval Postgraduate School’s Scientific and Visualization Lab (VisLab) 
contains a HP 730 workstation that is used as a HTTP server. Due to the increasing 
popularity of the World Wide Web, there is a concern that increases in the number of 
HTTP requests to this server will adversely affect the 10Base2 Ethernet network the 
server resides on. It is estimated that requests to this server may increase by 60 percent 
within the next year. Additionally, it is desired to determine the average amount of time 
necessary to process a HTTP request to the server and the effects of upgrading the 1 
gigabyte Connor SCSI hard drive installed to a 1 gigabyte Quantum SCSI hard drive. 

G. ANALYSIS AND OBJECT MAPPING 

The model which will be built to analyze the problem deals directly with the 
characteristics of the HP 730 and the processes the server performs in responding to 
HTTP requests. The basic characteristics of the HP 730 were obtained from Introduction 
to the Visualization Lab home page [Ref 3]. Data concerning server requests and the file 
sizes of the home pages most requested was obtained from the Statistics for the VisLab 
HTTP Server home page [Ref 4] which covers a time period of 120 days from 09/06/95 
to 01/03/96. 

1. Modeling of the HP 730 Workstation 

The parameters which are used to model the server when building the model are 
all estimates with the exception of the disk storage values. Hard drive specifications for 
Connor and Quantum 1 gigabyte SCSI hard drives were obtained from the Hard Drive 
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Spec home page [Ref. 5]. Both hard drives were assumed to have 120 sectors. 
Manipulation of the specifications to map them into C&C node parameters yields the 
following parameters as shown in Table 4.1. 


Manufacturer: 

Connor 

Quantum 

Model: 

CFP1080 

Atlas 

Disk Size (Mb): 

1080 

1075 

Sector Size (Kb): 

8789 

8748 

Data Transfer Time (microseconds): 

136636 

109248 

Seek Time (microseconds): 

11000 

8500 


Table 4.1 Hard Drive Parameters 


2. Modeling of HTTP Requests 

Figure 4.10 displays in a graphical form the cumulative number of requests made 
over the 120 day period by hour. The time period of concern is duririg normal working 
hours from 0800 to 1600. In order to use this data it must be converted to a form which 
may be used by a message source to model the interarrival time of HTTP requests. The 
assumption is made that the requests occur uniformly over the hourly time period as no 
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Figure 4.10 Cumulative Hourly HTTP Server Requests 
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information was available concerning the burstiness of the requests. The average time, in 
seconds, between requests was calculated, and a normal probability plot of these average 
times was constructed as shown in Figure 4.11. Based on this plot the average interarrival 
times for HTTP requests was chosen to be modeled as a normal distribution with a mean 
of 31.8 seconds and a standard deviation of 3.8 seconds. To model a 60 percent increase 
in HTTP requests, the number of requests per hour were scaled up by a factor of 60 
percent. The average interarrival time for each hour was then calculated. A 60 percent 
increase in requests was chosen to be modeled as a normal distribution with a mean of 
19.4 seconds and a standard deviation of 3.8 seconds. Table 4.2 displays the raw data 
used and the average interarrival times of packets calculated for each hour. 


Normal Plot of Average Inter-Arrival Time 
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Figure 4.11 Normal Probability Plot of Hourly Average Interarrival 
Times of HTTP Requests 


Data to describe the size of the HTTP requests was not collected, but was 
estimated to be a uniform distribution with a minimum of 10 bytes and a maximum of 
100 bytes. This estimate is based on the number of characters in a typical web server 
request. 
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Time 

Requests over 120 days 

Avg. Interarrival Time 
(sec) 

60% Increase in 
Requests 

Avg. Interarrival Time 
(sec) 

8 

11143 

38.8 

17828.8 

24.2 

9 

14306 

30.2 

22889.6 

18.9 

10 

14516 

29.8 

23225.6 

18.6 

11 

15350 

28.1 

24560.0 

17.6 

12 

15796 

27.3 

25273.6 

17.1 

13 

15282 

28.3 

24451.2 

17.7 

14 

14771 

29.2 

23633.6 

18.3 

15 

13095 

33.0 

20952.0 

20.6 

16 

12316 

35.1 

19705.6 

21.9 


Table 4.2 Hourly Web Server Requests 


3. Modeling of the Web Server Application 

As stated previously, the process that occurs at the server uppn receipt of a HTTP 
request may be modeled by an application source which reads a file and then creates a 
message to send back to requesting node based on the size of the file read. The modeling 
problem which occurs is how to estimate the number of bytes to read for each request. 
The file request statistics obtained from the Statistics for the VisLab HTTP Server home 
page [Ref. 4] contained information concerning the number of requests of the most 
frequently requested home pages. The individual portions of each home page which was 
still active were downloaded and summed to estimate the total number of bytes to be 
read. Table 4.3 contains a list of all pages which were active along with their file size and 
cumulative probability. This information may be used to create a distribution table to 
model the number of bytes to read upon receipt of a HTTP request. . 
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File Name 

Requests over 120 
Days 

Probability of 
Request 

Cumulative 

Probability 

File Size (Bytes) 

photo 

1280 

0.03 

0.03 

1295 

netiquette 

1265 

0.03 

0.06 

2154 

pirates 

2011 

0.04 

0.10 

6618 

npscompu 

1045 

0.02 

0.12 

8673 

origami 

1249 

0.03 

0.15 

9975 

edo 

2603 

0.05 

0.20 

14494 

sfgram 

849 

0.02 

0.22 

14857 

helos 

850 

0.02 

0.24 

16650 

cfbush 

2165 

0.04 

0.28 

17040 

thesis 

710 

0.01 

0.29 

17053 

mclinks 

1337 

0.03 

0.32 

18197 

nsgdhome 

1566 

0.03 

0.35 

21797 

bkandber 

1041 

0.02 

0.37 

25875 

psu 

1936 

0.04 

0.41 

28188 

photo gallery 

1378 

0.03 

0.44 

30167 

chi 

847 

0.02 

0.46 

30365 

direc 

1990 

0.04 

0.50 

30420 

c4i-pro 

820 

0.02 

0.52 

36514 

library 

1409 

0.03 

0.55 

39625 

marine 

6579 

0.14 

0.69 

41829 

fapapoul 

1667 

0.03 

0.72 

62230 

opnsrsch 

850 

0.02 

0.74 

69609 

habitatmc 

1090 

0.02 

0.76 

72317 

jcking 

1028 

0.02 

0.78 

96015 

oa2200 

724 

0.01 

0.79 

127800 

braccio 

1326 

0.03 

0.82 

134370 

pelopon 

908 

0.02 

0.84 

136681 

history 

989 

0.02 

0.86 

136681 

macedon 

3887 

0.08 

0.94 

136681 

ece 

1128 

0.02 

0.96 

149812 

maps 

1122 

0.02 

0.98 

296816 

pictures 

1039 

0.02 

1.00 

526065 


Table 4.3 File Size and Cumulative Probability Table 


H. BUILDING THE MODEL 

The building of the model described in the following subsections is done by 
creating objects or parameter sets one step at a time with detailed instructions on how to 
complete the step. The completed model should look similar to that shown in Figure 4.12. 
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1. Defining Computer and Communications Node Parameters 

The parameter sets for the computer and communications nodes are defined first 

so that they may be applied later when the nodes are created. 

a) From the Define menu select the Nodes/Computer and Communications option. 

b) Edit the node parameters to the following parameters: 

• Name: HP 730 CONNOR HD 

• Source or sink box: checked 

• Processing/cycle: 0.02 microseconds 

• Time slice: Set to a normal distribution with a mean of 100000 microseconds 
and a standard deviation of 10000 microseconds. The stream value may be any 
value from 0 to 99. 

• Packet processing: Edit to model a 0.01 millisecond delay for the IP protocol. 

• Port Processing: Edit to model a delay of 0.01 milliseconds for the CSMA/CD 
link and the IP protocol for both input and output delays. 

• Default port processing: Set to a delay of 0.05 milliseconds for input and 
output Buffer Max: Set to 4194304 bytes for both the input and output to 
model 4Mb total available for each. 

• Disk: 1080 Mb 

• Sector: 8789 Kb 

• Transfer rate: 163636 microseconds 

• Seek: 11000 microseconds 

c) When all the values have been entered, press the Done button at the bottom of the 
window. 
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d) Create a second parameter set using the same values as in step b with the following 
exceptions: 

• Name: HP 730 QUANTUM HD 

• Disk: 1075 Mb 

• Sector: 8748 Kb 

• Transfer rate: 109248 microseconds 

• Seek: 8500 microseconds 

e) When all the values have been entered, press the Done button at the bottom of the 
window. 


2. Creating the Ethernet Link 

The following steps describe the creation and editing of the Ethernet link: 

a) Create a collision link using either the toolbar or the Create menu. 

b) Edit the link to set the following parameters such as shown in Figure 4.13: 

• Name: ETHERNET 

• Type: CSMA/CD 

• Parameters: 802.3 CSMA/CD 10BASE2 



Figure 4.13 Link Detail Window 


c) When all values have been entered press the OK button. 
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3. Creating the Web Server and Message Generator Nodes 

The following steps detail the methods of creating the C&C nodes to model the 
web server and a message generator: 

a) Create two C&C nodes using either the toolbar or the Create menu. 

b) Edit one of the nodes to the following parameters: 

• Name: WEB SERVER 

• Type: Computer and Communications Node 

• Parameters: HP 730 CONNOR HD 

c) Edit the second node to the following parameters: 

• Name: MSG GENERATOR 

• Type: Computer and Communications Node 

• Parameters: DEFAULT 

d) Create the ports to connect the two nodes to the ethemet link using either connection 
tool on the toolbar, and edit the port attached to the WEB SERVER node such that 
both the input and output buffers are set to 262144 bytes to model a 256 Kb buffer on 
the port. 

4. Creating Message Source Distributions 

Prior to creating the message source for the generation of the HTTP requests, the 
two distributions which will be used to model the interarrival time of current HTTP 
requests and a 60 percent increase in requests is created using the following steps: 

a) Select the User Distribution option on the Define menu. 

b) In the window which appears press the Add button. 

c) Edit the distribution to the following parameters as shown in Figure 4.14: 

• Name: O.PERCENT 

• Sample: Set to a normal distribution with a mean of 31.8 seconds and a 
standard deviation of 3.8 seconds. The stream value may be set to any value 
between 0 and 99. 
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Figure 4.14 0_PERCENT User Defined Distribution 

d) When all values are entered, press the OK button as shown in Figure 4.14. Then, press 
the Add button again to create a second distribution. 

e) Edit the second distribution to the following parameters; 

• Name: 60_PERCENT 

• Sample: Set to a normal distribution with a mean of 19.4 seconds and a 
standard deviation of 3.8 seconds. The stream value may be set to any value 
between 0 and 99. 

f) When all values are entered, press the OK button to clear this window, and the Done 
button to clear the second window. 


5. Creating the HTTP Requests Message Source 

The following defines the steps necessary to create the message source used to 
model the HTTP requests which will be attached to the MSG GENERATOR node in the 
model: 

a) Create a message source using either the toolbar or the Create menu and place it near 
the MSG GENERATOR node. 

b) Use either of the connection tools to connect the message source to the MSG 
GENERATOR node. 

c) Edit the message source entering the parameters shown in the following list and also 
in Figure 4.15: 

• Name: WEB REQUEST 

• Schedule by: Iteration Time 

• Interarrival: Set to the 0_PERCENT distribution 

• Priority: 1 

• Routing Class; Standard 
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• Transport Protocol: TCP/IP-Sun 

• Packetize: 0.01 milliseconds 

• Message Size Calculation: Probability Distribution 

• Probability Distribution: Set to a uniform distribution with a minimum of 10 
bytes and a maximum of 100 bytes. The stream value may be set to any value 
between 0 and 99. 

• Message text option: Copy Message Name 

• Destination Type: Set to weighted list. Create a list adding only the WEB 
SERVER. 



Iteration time 


lOO^PERCENT 
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Probability cfoUibution 
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Figure 4.15 Web Request Message Source Parameters 


d) When all parameters have been set, press the OK button at the bottom of Figure 4.15. 


6. Creating a Distribution Table 

The distribution table will be used in a read command to model the number of 
bytes read upon the receipt of the WEB REQUEST message. 

a) From the Define menu select the Tables option. 

b) In the tabular distribution window which appears select the Add button. 

c) Edit the fields in the table detail window to the following values as shown in 
Figure 4.16: 
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• Name: WEB_READ 

• Table type: discrete 

• Probability and Values: Edit the probability and values pairs such that the 
probability values are set to the cumulative column and the values are set to 
the file size column of Table 4.3. 



Figure 4.16 WEB_READ User Defined Table 


d) When all values are entered in the table detail window, press the View button at the 
bottom of the window. A plot of the distribution entered as shown in Figure 4.17 will 
appear. 

e) Clear the plot of the distribution; press the OAT button at the bottom of the table detail 
window; and press the Done button at the bottom of the tabular distribution window. 
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Figure 4.17 WEB_READ Discrete Distribution 


7. Creating the Application Read Command 

The read command will be used in a application source to execute a read to the 
local disk of the WEB SERVER node. 

a) Double click on the WEB SERVER node icon to bring up the node detail window and 
press the Command button in this window. 

b) In the command repertoire window which appears press the Add hnXion. 

c) In the library selection window that appears select the Read File option. 

d) Set the parameters of the read command window to the values shown in the following 
list and also shown in Figure 4.18. 

• Read command name: WEB PAGE READ 

• File to access: GENERAL STORAGE 

• File modification method: Do not modify file 

• Bytes read calculation: Probability distribution 

• Probability distribution: WEB_READ 
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Figure 4.18 WEB PAGE READ Command 


e) When all values have been entered, press the OK button in the read command 

window; press the Done button in the command repertoire window; and press the OK 
button in the node detail window to clear these windows. 


8. Creating the Application Answer Command 

The answer command will be used in an application to model the generation of 
the message to be sent based on the size of the file read using the WEB PAGE READ 
command. 

a) From the Define menu choose the Global Commands option. 

b) In the command repertoire window which appears select the Add button. 

c) In the library selection window select the Answer Message option from the list. 

d) Set the answer command fields to the following values as shown in Figure 4.19: 

• Name: WEB ANSWER 

• Priority: 1 

• Routing class: Standard 

• Transport protocol: TCP/EP - Sun 

• Packetize: 0.01 milliseconds 

• Message size calculation: (A x File Bytes) + B 

• A: 1.000 

• B: 0.000 

• Message text option: Copy message name 
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Figure 4.19 WEB ANSWER Command 


e) When all values are entered, press the OK button at the bottom of the answer 
command window, and the Done button at the bottom of the command repertoire 
window to clear these windows. 


9. Creating the Web Server Application Source 

The application source will utilize the commands previously created to model the 
processes that will occur on the WEB SERVER node upon receipt of a HTTP request. 

a) Create an application source using either the toolbar or the Create menu and place the 
source near the WEB SERVER node. 

b) Using either connection tool on the toolbar connect the application source to the WEB 
SERVER node. 

c) Edit the application source fields to the following values as shown in Figure 4.20: 

• Name: WEB RESPONSE 

• Schedule by: Received message 

• Received message delay: none 


74 


































Figure 4.20 WEB RESPONSE Application 

d) Using the Edit Received Messages... button add the WEB REQUEST message to 
trigger this application upon the receipt of only one message. 

e) In the command sequence portion as shown in Figure 4.20, press the Add button. A 
window as shown in Figure 4.21 will appear. Using the drop down list, select the 
WEB PAGE READ command and set the number of executions to 1. 



Figure 4.21 Command Name Detail Window 

f) Press the OK button in the command name detail window, and then press the Add 
button again. Select the WEB ANSWER command, set the number of executions to 
1, and press the G/T button. 
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g) Press the OK button at the bottom of the application source window to complete 
building the application. 

10. Verifying and Saving the Model 

The final step in completing the model is to select the Verify Model option on the 
Simulate menu to check for any errors. The message bar should indicate No verification 
errors detected. If errors in the model are present a window will appear showing the 
errors. Any errors must be corrected prior to running a simulation. Finally, save the model 
selecting the Save or Save A 5 option from the File menu. 

1. SIMULATION AND RESULTS 

Three simulation runs will be used to collect the data needed to analyze the 
problem. The following reports need to be selected prior to running the simulation: 

• Links: Channel Utilization for the ETHERNET link 

• Application Sources: Application Run Length for the WEB RESPONSE 
application. 

The length of each run in the simulation should be set to 3600 seconds to simulate an 
hour of simulated requests to the server. After completion of the first run, a text file 
named report. 1 will be created. The name of this file should be changed to prevent 
overwriting the file during the subsequent simulations. Before starting the second 
simulation, edit the MSG GENERATOR message source so that the interarrival time is 
set to the 60_PERCENT user-defined distribution. Run the second simulation, and again 
change the name of the report generated at the end of the simulation so that it will not be 
overwritten by the report generated by the third simulation. Before running the third 
simulation, edit the MSG GENERATOR message source again to set the interarrival 
distribution back to the 0_PERCENT user-defined distribution, and edit the WEB 
SERVER node to change the parameters field to HP 730 QUANTUM HD. After these 
changes have been made run the third simulation. 

The simulation results for the current level of HTTP requests to the server showed 
that these requests and web pages being sent represent very little utilization of the 
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network (0.19%). An increase of 60 percent in HTTP requests will increase the utilization 
of this network minimally (0.31%). The average delay in processing a HTTP request in 
the simulation was 256 milliseconds for simulations run modeling the Connor hard drive 
irrespective of the traffic level. The simulation run with the Quantum hard drive showed a 
decrease in processing the requests to 187 milliseconds. This decrease in processing times 
was expected due to the faster seek time and transfer rate of the Quantum hard drive over 
the Connor hard drive. 

The modeling of the problem was chosen to be done to isolate the effects of 
HTTP requests alone on the network and server. Other traffic on the network which was 
not modeled would add greater validity to the model if other parameters such as the 
latency for packets across the network were desired to be determined. 


77 






78 



V. APPLICATION SOURCES AND COMMANDS 


A. INTRODUCTION 

The goal of this chapter is to introduce the user to the application source and the 
commands available in COMNET IE to script the processes which may occur in an 
application source. The use of application sources will then be shown in a model which 
deals with changing a peer-to-peer network into a client-server architecture. 

B. APPLICATION SOURCES 

Application sources are used in COMNET HI to model workload on a node and to 
create more complex processes on a node than can be defined using message, response, 
and session sources. The processes which occur in an application source are scripted 
using commands. When an application source is scheduled to run on a node, the node will 
sequentially execute each command defined until the entire application has been 
completed. Application sources may only be used with computer and communications 
nodes, computer group nodes, and router nodes. 

The scheduling of an application source may occur in three different ways. 
Iteration time scheduling is one method of time-based scheduling which sets the time 
from the start of one instance of an application to the start of the second instance. The use 
of iteration time scheduling may cause the multiple overlapping application to be present 
on a node at the same time [Ref. 2 p. 185]. If only one application source is needed to be 
modeled on a node at a time, then delay time scheduling should be used. In this second 
method of time-based scheduling, the interarrival time is used to set the time between the 
end of one instance of the application and the start of the next instance. The final method 
of scheduling is by received message. In this case the application will trigger upon receipt 
of a message of the required text at the node. 

Application sources may be created either by using the toolbar or the Create 
menu. Editing of the application source will cause the apphcation source window shown 
in Figure 5.1 to apjiear. The parameters fields shown are used to set the scheduling of the 
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application source, and to script the commands which are to be executed within the 
application source. The fields shown in Figure 5.1 have the following uses: 

• Name: Used to set a unique name to the application source to distinguish it 
from other application sources in the model. 

• Schedule by: Used to set the method of scheduling to either delay time, 
iteration time, or received message. 

• Edit Received Messages ... Button: The button becomes active when received 
message scheduling is used. It allows creating a list of the number of messages 
required and there associated text which may be used to trigger the 
application. 

• Interarrival: Used with both time-based scheduling to set the interarrival time 
between ^plication instances. This field may be set to a constant value or to 
any statistical distribution. 

• First arrival: Used with time-based scheduling to set in simulation time when 
the first instance of the application is to occur. This field may be set to none, a 
constant value, or to any statistical distribution. 

• Last arrival: Used with time-based scheduling to set in simulation time when 
the last instance of an application will occur. This field may be set to none, a 
constant value, or to any statistical distribution. 

• Maximum arrivals: Used in time-based scheduling to limit the number of 
instances of an application source which may occur in one simulation 
repetition. This field may be set to none, a constant value, or to any statistical 
distribution. 

• Received message delay: Used with received message scheduling to set a 
delay in the start of the application source after the receipt of the message 
which triggers the source. This field may be set to none, a constant value, or to 
any statistical distribution. 

• Command Sequence: This field is used to script the commands which will be 
executed in the application source. The buttons to the right of this field allow 
editing the order in which commands appear and the number of times each 
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command is to execute. Pressing the Add, Add Before, or Add After buttons 
will bring up the window shown in Figure 5.2 used to enter commands. 



Figure 5.1 Application Source Window 



Figure 5.2 Application Command Name Detail Window 
C. APPLICATION COMMANDS 

Application commands are used to script the processes which may occur within an 
application source. They may be defined globally within a model by using the Global 
Commands option in the Define menu, or locally by using the Command button in the 
dialog box of the computer and communications node, computer group node, or router 
node. Global commands are available for use by any application source created in a 
model. Local conunands reside only on the node they are created on and become 
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available for use in an application source only after the source is connected to the node. A 
global and local command within the same model may be given the same name. When 
executing the application’s command sequence during a simulation, the application 
source first checks the list of local commands available on the node. If the command is 
not found, it will then check the global command list. Thus, a local command takes 
precedence over a global command with the same name. 

When creating a command, whether local or global, the first window that will 
appear is the command repertoire window shown in Figure 5.3. Commands are created by 
selecting the Add button in this window which will activate the library selection window 
shown in Figure 5.4. The library selection window contains a list of all the commands 
which may be constructed in COMNET HI. By selecting a command from this window 
with a single click of the mouse, a window will appear which enables the editing the 
parameters of the command. 



Figure 5.3 Command Repertoire Window 
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Figure 5.4 Library Selection Window 


1. Answer Message Command 

The answer message command is used to create a message which is to be sent 
back to node that triggered the application source. The logic which occurs within the 
COMNET in application upon the execution of this command is the same as for a 
response source which was covered in Chapter HI. When the answer message command 
is selected, the window shown in Figure 5.5 will appear. The fields which may be edited 
in this window have the same function as the fields for the response source with the 
following exception. The message size of a answer message command may also be based 
upon the size of the first file read within an application source by a read command. 



Figure 5.5 Answer Command Window 
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2. Filter Message Command 

The filter message command is used to suspend the execution of an application 
source until a message is received which fulfills the requirements of the filter [Ref. 2 p. 
46], If a message received at a node may be used to fulfill the requirements of the filter, 
or trigger an application source, the filter command takes priority over the creation of the 
new application instance. This command is very useful in modeling of a client-server 
architecture where an application source will send a request to a node and must then wait 
for the response before the process may continue. Additionally, if situations arise in the 
modeling of an application where a message to be sent needs to be based on the size of a 
message received and the application source is not scheduled by received message, a filter 
command must be used to capture the received message for later use by an answer or 
transport command. Errors will occur when verifying the model if the filter command is 
not used in this situation. 

When a filter command is created, the window shown in Figure 5.6 will appear. 
The window allows entering a unique name to the command and setting the text of the 
received message the filter is waiting for. The latter may be accomplished by choosing the 
text from the drop down list or by explicitly typing in the required text. 



Figure 5.6 Filter Command Window 

3. Process Data Command 

The process data command may be used in an application source to simulate 
workload on a node, or as a spacer to separate the execution of commands by a certain 
amount of time. This command is scaled in units of number of cycles. The amount of 
time necessary to complete the cycles is based on the processing/cycle value set on the 
node the application source is connected. 
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When a process data command is created the window shown in Figure 5.7 will 
appear. The fields of this window allow entering a unique name for the command and 
offer three different methods to determine the number of cycles the command is to 
execute shown in the following list: 

• Based on a probability distribution 

• Based on message size: This method uses the linear relationship 

Number of Cycles = A * Message Size + B 
to determine the number of cycles. To use this option the application must 
either use received message scheduling or the processing command must be 
preceded by a filter command. 

• Based on file size: This method uses the linear relationship 

Number of cycles = A * Number of Bytes Read + B 
to determine the number of processing cycles. To use this option the process 
command must be preceded by a read command. 



Figure 5.7 Process Command Window 

4. Read File Command 

The read file command is used in an application source to model the time delay 
associated with reading a file from a node’s local disk. When a read command is invoked, 
the following logic is applied to the execution of the command [Ref. 2, p. 50,51]: 

1. The file to be read is locked for exclusive use by the read command. 
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2. The time duration of the command is calculated based upon the disk 
parameters of the node. 

3. The nodes processor is made busy for the time calculated in Step (2). 

4. After completion of the delay the file information is updated, and the file is 
unlocked. 

Creation of a read command causes the window shown in Figure 5.8 to appear. 
The fields of this window allow specifying a distinct name to identify the command, and 
the file to access on the node’s disk. The file modification field allows the following 
options; 

• Do not modify: File size is unchanged after a read command 

• Decrement file: File decrements in size by the number of bytes read. 

• Delete file: The file is deleted after reading the required number of bytes. 

The bytes read calculation may be based on any of the following options: 

• Entire file: The number of bytes the file has defined are read. 

• Probability distribution 

• Based on message size: This option may only be selected if the application 
uses received message scheduling. The size calculation is based on the liner 
relation ship 

Bytes Read = A * Message Size + B. 

• Based on file size: If a previous read command has been executed in an 
application source, subsequent read corrunands may be based on the number 
of bytes read by the first read command using the linear relationship 

Bytes Read = A * First Number of Bytes Read + B. 
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Figure 5.8 Read Command Window 


5. Setup Session Command 

The setup session command is used to model the establishment of switched or 
permanent virtual circuits or for modeling any connection oriented messages. The logic 
applied when a setup session command executed is the same as for a session source 
which was described in Chapter III. 

Creation of a setup session command will cause the window shown in Figure 5.9 
to appear. The parameter fields associated with the setup command are the same as those 
of a session source. 



Figure 5.9 Setup Command Window 
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6. Transport Message Command 

The transport command is used to model connectionless data transport across a 
network. The logic which applies upon the execution of a transport command is the same 
as applied to a message source which was described in Chapter III. 

Creation of a transport command will cause the window shown in Figure 5.10 to 
appear. The parameters associated with the transport command are the same as for a 
message source with the exceptions that the scheduling method is not included, as this is 
done by the application source, and the message size calculation may also be based on the 
size of a file previously read. 



Figure 5.10 Transport Command Window 

7. Write File Command 

The write file command is used to model the time delay associated with writing a 
file to a node’s local disk. The logic applied by the program when a write command is 
executed is the same as for a read command. 

The creation of a write command will cause the window shown in Figure 5.11 to 
appear. The fields in this window allow specifying a unique name for the command, and 
the file to access on the local disk. The three file modification methods available are as 
follows; 
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• Append: The file size is increased by the number of bytes wrote to the file. 

• Replace: The file is replaced by the number of bytes written. 

• Update: The file size is not changed, but the delay used to write the file is 
incurred on the node. 

The three options available to determine the bytes to write are by probability distribution, 
based on message size, or based on file size. These three options are executed in the same 
manner as for a read command. 



Figure 5.11 Write Command Window 

D. PROBLEM STATEMENT 

The Systems Technology Lab has seven Pentium 90 MHz personnel computers 
connected to a 10Base2 ethemet network in a peer-to-peer arrangement. These computers 
are commonly used by students for thesis writing and for preparing presentations. The 
major problem with this network configuration is the time spent in configuration 
management of the applications which reside on each computer. This has required the 
reloading of all applications on each computer at the end of every quarter. Students have 
also voiced complaints about the lack of disk storage space available in the lab for 
maintaining their files. 

To alleviate configuration management problems and to create disk storage space 
the lab has purchased a Pentium 90 MHz computer which has four processors and 
multiple 1 Gbyte hard drives, and is planning to mn this computer using the Windows 
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NT“" operating system. This computer will be used as both an application and file server. 
The lab desires an estimate of the increase in network loading and collisions during peak 
usage hours, and estimates of the application delays on the application and file server. 

E. ANALYSIS AND OBJECT MAPPING 

The modeling of a shift of a peer-to-peer network to a client-server architecture 
requires not only the modeling of the hardware which makes up the network, but also 
estimates of the most commonly used programs used in the lab which will now generate 
additional traffic due to file requests and the transfer of applications across the network. 
Four applications can be created to model these changes to a client-server architecture. 

• An application server application which will read a program from the 
application server’s hard drive and transfer a copy of the program to the 
requesting computer. 

• A file request application which reads files from the file server and transfers 
the file to the requesting computer. 

• A save application which models the saving of files to the file server hard 
drive. 

• A user application which models the behavior of users in requesting programs, 
requesting files, saving files, and printing documents. 

1. Modeling of the Application Server’s Application Source 

The application server’s application source may be constructed by creating a 
simple model of a read command followed by an answer command. Upon receipt of a 
request for a program at the application server, the file requested is read from the server’s 
hard drive, and a copy of the program is sent across the network to the computer where 
the request was generated. 

Instead of modeling the entire file structure of the application server, the program 
to be read upon receipt of a request was chosen to be modeled using a probability table. 
This choice was made to simplify the modeling for the entire problem as the requests for 
a program cannot be modeled to specify which file to read. The specification of reading a 
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file may only be done in an application source which implies that an application source 
for every program accessible on the server would need to be created. Estimates for the 
most commonly used programs in the lab indicated that the Microsoft Office Suite were 
used to the greatest extent. To estimate the file size which would need to be read by the 
application server the programs were individually launched and the amount of memory 
the program occupied was determined using the System Information Utility of the Norton 
Utilities for Windows 95“” application. The amount of memory required for each 
application was then used to estimate the file size to read. The individual application file 
sizes along with the estimated probabilities of the request being for that application are 
summarized in Table 5.1. From the file size read, an answer command may be created to 
transport the program to the requesting node using the TCP/IP-Microsoft transport 
protocol with a 1 millisecond packetizing delay. 


Application 

Probability 

Cumulative Probability 

File Size (bytes) 

Excel 

0.2 

0.2 

637000 

PowerPoint 

0.3 

0.5 

1370000 

Word 

0.5 

1.0 

1440000 


Table 5.1 Program Cumulative Probabilities and File Size 


2. Modeling of the File Server’s File Request Application Source 
The process that occurs on the file server upon receipt of a file request may be 
modeled using a processing command, a read command, and an answer command. The 
processing command models the processing necessary to find a file in the file allocation 
table based on the size of the file request message with no scaling of the message size. 
The read command models the reading of the requested file from the file server’s hard 
drive. Again, an entire file structure of the server was not constructed to simplify the 
modeling of the problem. File sizes to be read are estimated to follow a normal 
distribution with a mean of 150000 bytes and a standard deviation of 50000 bytes. Upon 
completion reading the file, an answer command is used to transport the file to the 
requesting computer using the TCP/IP-Microsoft transport protocol and a packetizing 
delay of 1 millisecond. 
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3. Modeling of the File Server’s Save Application Source 

The modeling of the save application source may be performed by the use of a 
write command. Processing of the packets which make up the message is performed by 
the node’s processor upon receipt of the packet. A write command based on the size of 
the message will model the writing of this message to the file server’s hard drive. 

4. Modeling of the Personal Computer’s Application Source 

To model the behavior of the users on the personal computers during peak usage, 
it was estimated that a single computer remained vacant for a time period which followed 
a uniform distribution ranging from 5 to 15 minutes after a user completed work. Also, 
the assumption was made that only one program was in use on the computer at a time. In 
order to randomize the time that the first instance of an application occurred on each 
computer, the first arrival was estimated to follow a uniform distribution and occur in the 
range of 0 to 10 minutes of simulation time. 

The first operation expected of the computer users is to request the launch of an 
program from the application server. This action is modeled as a transport command 
where the message size is estimated to be a constant of 125 bytes in length. The computer 
must then wait for the application server’s response which implies a filter command be 
used to suspend the application source. Upon receipt of the copy of the program the 
computer processes for a period of time based on the size of the message which is 
modeled using a processing command. 

To model the worst case in traffic loading on the network, the assumption is made 
that the computer user then requests a file from the file server. This action may also be 
modeled using a transport command with the message size estimated to be 100 bytes in 
length. Again, the application source must wait for the file to be transferred which again 
implies the use of a filter command to suspend the application source. 

The application source resumes executing upon receipt of the file requested. It 
was assumed that the computer user would then work for 15 to 20 minutes and save their 
work. The 15 to 20 minutes of processing may be modeled using a processing command 
set to a uniform distribution scaled to the processing/cycle value of the node to achieve 
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the time delay needed. The save action may be modeled by a transport command to the 
file server which transfers a file scaled which is scaled to be 10 percent greater than the 
file earlier retrieved. 

Upon completion of saving the file, it was again assumed the computer user 
would again process for 15 to 20 minutes which may be modeled in the same fashion as 
before. The user then requests printing of the document and saves the document. The 
printing of the document to the laser printer located in the lab may be modeled by a 
transport command with the message size scaled to a factor of 20 percent greater than the 
original file size. The save command may be modeled as the previous save but with the 
message to be transferred also scaled 20 percent greater than the original message 
received from the file transfer. 

All messages which will be created by this application use the TCP/IP-Microsoft 
transport protocol with the exception of print requests to the laser printer which use the 
NCP/IPX transport protocol. All messages are also assumed to have a packetizing delay 
of 1 millisecond. 

5. Modeling of the Network Computers 

The computer purchased by the Systems Technology Lab to be used as both the 
application and file server has multiple processors. However, COMNET HI currently does 
not have an object available to model a multiprocessor computer. The decision was made 
to model the application and file server as two separate machines using computer and 
communications nodes. The values of the parameter set used to describe the servers are 
given in Section F of this chapter. 

The seven personal computers used in the lab could be modeled separately as 
seven computer and communications nodes or by using a single computer group node. 
The latter option was chosen to minimize clutter in the work area. The values of the 
parameter set used to describe the personal computers are given in Section F of this 
chapter. 

The laser printer in the lab may also be modeled using a computer and 
communications node. Since the laser printer is used in the model only as a destination 
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for message traffic, the default parameter set of the computer and communications node 
is used to describe the printer. 

F. BUILDING THE MODEL 

This section provides step-by-step instructions for each object which needs to be 
created to model the problem. Figure 5.12 shows a view of the completed model 
topology. 



1. Deflning the Application and File Servers Parameter Sets 

The following instructions define the steps for building the parameter set to be 
used in modeling the application and file server: 

a) From the Define menu select the Nodes Parameters/Comp and Comm option. 

b) In the computer and communications node parameters window which appears select 
the Add button. 

c) Edit the fields of the node parameter window to the following follows; 

• Parameter set name: NT Server 

• Processing/cycle: .0111 microseconds 

• Time slice: Set to a uniform distribution with a minimum value of 100 and a 
maximum value of 1000000 microseconds, the streams value may be set to 
any integer value between 0 and 99. 
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• Packet Processing: Use the Edit Times... button to create a delay of 0.01 
milliseconds for the IP protocol. 

• Port Processing: Use the Edit Times... button to create an input and output 
delay of 0.01 milliseconds for the IP protocol on a CSMA/CD link. 

• Default times: Set to 0.05 milliseconds for both input and output buffers. 

• Buffer max: Set to 4194304 bytes for both the input and output buffers. 

• Disk: 1024 Mb 

• Sector: 0.5 Kb 

• Xfer: 13 microseconds 

• Seek: 12000 microseconds 


d) When all values have been entered, press the OK button at the bottom of the node 
parameter window, and then press the Done button at the bottom of the computer and 
communication node parameter window. 


2. Defining the Systems Technology Lab Computer Parameter Sets 
The following steps define the creation of the parameter set which will be used to 
model the seven personal computers located in the Systems Technology Lab: 

a) From the Define menu select the Node/Computer Group option. 

b) In the computer group parameters window which appears select the Add button. 

c) Edit the fields of the computer group parameters window that appears to the 
following: 

• Parameter set name: STL PC’s 

• Processing/cycle: 0.0111 microseconds 

• Time slice: none 

• Packet processing: Use the Edit Times button to set a 0.01 millisecond delay 
for IP packets and a 0.05 millisecond delay for IPX packets. 

• Port Processing: Use the Edit Times button to create for the CSMA/CD link 
type a 0.01 millisecond input and output delay for IP packets, and a 0.05 
millisecond input and output delay for IPX packets. 

• Default times: Set to 0.05 milliseconds for both the input and output buffers. 

• Buffer max: Set to 4194304 bytes for both the input and output buffers. 

• Disk: 540 Mb 

• Sector: 0.5 Kb 

• xfer: 13 microseconds 

• Seek: 12000 microseconds 
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d) When all values have been entered, press the OK button at the bottom of the computer 
group parameter window, and then the Done button to clear the remaining window. 


3. Building the Network Topology 

The following section defines the steps necessary to create each object needed to 
build the model topology and the parameters associated with these objects: 

a) Create a collision link icon using either the toolbar or the Create menu. Edit the link’s 
parameters to the following: 

• Name: 63 Net 

• Type: CSMA/CD 

• Parameters: 802.3 CSMA/CD 10BASE2 

b) Create three computer and communication nodes which will be used to represent the 
application server, file server, and the laser printer. 

c) Edit the node to be used as the application server to the following parameters: 

• Name: Application Server 

• Type: Computer and Communications Node 

• Parameters: NT server 

d) Edit the node to be used as the application server to the following parameters: 

• Name: File Server 

• Type: Computer and Communications Node 

• Parameters: NT server 

e) Edit the node to be used as the application server to the following parameters: 

• Name: STL Laser Printer 

• Type: Computer and Communications Node 

• Parameters: Default 

f) Create one computer group node and edit the node to the following parameters: 

• Name: STL PC’s 

• Type: Computer Group 

• Parameters: STL PC’s 

g) Using either of the connection tools on the toolbar, connect all of the nodes created to 
the 63 Net link. Edit the port extending to each node so that the input and output port 
values are set to 262144 bytes. 
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4. Creating the Personal Computer Application Source 

I 

The application source which will run on the personal computers will be built by 
first defining the commands which will be used in this application, and then creating the 
application source. 

a) Define a global transport command and edit the parameters of this field to those 
shown in the following list. Figure 5.13 displays the completed command. 

• Name: MS Office Request 

• Message Size Calculation: probability Distribution 

• Probability distribution: Set to a constant value of 125 bytes 

• Message text option: Copy message name 

• Priority: 1 

• Routing Class: Standard 

• Transport protocol: TCP/IP-Microsoft 

• Packetize: 1.0 millisecond 

• Destination Type: Set to a weighted list and create a list containing only the 
Application Server node. 

b) When all values have been entered press the OK button as shown in Figure 5.13 and 
then define a global filter command. 



I Standard 


TCP/IP 


Probability disbibution 


Weighted M 


Transport Command 


|MS Office RequesI 


Figure 5.13 MS Office Request Transport Command 


c) Edit the filter command parameters to those of the following list and shown in Figure 
5.14. 
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Filter Command Name: MS Office Wait 
Required message text: Set to MS Office Answer 



Figure 5.14 MS Office Wait Filter Command 

d) When all values have been entered press the OK button as shown in Figure 5.14 and 
then define a global processing command. 

e) Edit the processing command to the value defined in the following list and also 
shown in Figure 5.15. 

• Processing command Name: MS Office Processing 

• Number of cycles calculated: (A x Msg Bytes) + B 

• A: 1.00 

• B: 0.00 



Figure 5.15 MS Office Processing Command 


f) When all values have been entered press the OK button as shown in Figure 5.15 and 
then define a global transport command. 

g) Edit the transport command parameters to those of the following list and shown in 
Figure 5.16. 

• Name: File Request 
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• Message Size Calculation: probability Distribution 

• Probability distribution: Set to a constant value of 100 bytes 

• Message text option: Copy message name 

• Priority: 1 

• Routing Class: Standard 

• Transport protocol: TCP/IP-Microsoft 

• Packetize: 1.0 millisecond 

• Destination Type: Set to a weighted list and create a list containing only the 
File Server node. 


h) When all values have been entered, press the OK button as shown in Figure 5.16 and 
then define a global filter command. 

i) Edit the parameters of the filter command to the following values: 

• Filter Command Name: File Request Wait 

• Required message text: Set to File Request Answer 

j) When all values have been entered, press the OK button in the filter command 
window, and then define a global processing command. 



Figure 5.16 File Request Transport Command 

k) Edit the parameters of the processing command to the following values and as shown 
in Figure 5.17: 

• Processing command Name: Application Processing 
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• Number of cycles calculated: Probability Distribution 

• Probability distribution: Set to a uniform distribution with a minimum value 
of 81,000,000,000 cycles and a maximum value of 108,000,000,000 cycles. 



^ Nl>r 


Probability distribution 


Uni(ei 000000000.0.1080 


Process Command 


Figure 5.17 Application Processing Command 


l) When all values have been entered, press the OK button as shown in Figure 5.17, and 
then define a global transport command. 

m) Edit the transport command parameters to those of the following list and shown in 
Figure 5.18. 

• Name: Save Request 1 

• Message Size Calculation: (A x Msg Bytes) + B 

• A: 1.100 

• B: 0.000 

• Message text option: Copy message name 

• Priority: 1 

• Routing Class: Standard 

• Transport protocol: TCP/IP-Microsoft 

• Packetize: 1.0 millisecond 

• Destination Type: Set to a weighted list and create a list containing only the 
File Server node. 
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Figure 5.18 Save Request 1 Transport Command 


n) When all values have been entered, press the button as shown in Figure 5.18, and 
then define another global transport command. 

o) Edit the transport command values to those of the previous transport command 
defined with the following exceptions: 

• Name: Save Request 2 

• A: 1.200 

p) When all values have been entered, press the OAT button and then define another 
global transport command. 

q) Edit the transport command parameters to those shown in the following list: 

• Name: STL PC Print Request 

• Message Size Calculation: (A x Msg Bytes) + B 

• A: 1.200 

• B: 0.000 

• Message text option: Copy message name 

• Priority: 1 

• Routing Class: Standard 

• Transport protocol: NCP 

• Packetize: 1.0 millisecond 

• Destination Type: Set to a weighted list and create a list containing only the 
STL Laser Printer node. 
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r) When all values have been entered, press the OK button in the transport command 
window, and then press the Done button in the command repertoire window. 

s) Create an application source and place it next to the STL PC’S node. 

t) Using either connection tool connect the application source to the STL PC’S node. 

u) Edit the application source fields to the following list and as shown in Figure 5.19: 

• Name: Office Application 

• Schedule by: Delay Time 

• Interarrival: Set to a uniform distribution with a minimum value of 300 
seconds and a maximum value of 900 seconds. The stream value may be set to 
any integer value from 0 to 99. 

• First arrival: Set to a uniform distribution with a minimum value of 0 seconds 
and a maximum value of 600 seconds. The stream value may be set to any 
integer value from 0 to 99. 

• Last Arrival: none 

• Maximum arrivals: none 

v) In the command sequence box shown in Figure 5.19, use the Add button to script the 
commands in the following order where each command executes only one time. 

1. MS Office Request 

2. MS Office Wait 

3. MS Office Processing 

4. File Request 

5. File Request Wait 

6. Application Processing 

7. Save Request 1 

8. Application Processing 

9. STL PC Print Request 

10. Save Request 2 
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Figure 5.19 Office Application Application Source 


w) When all values have been entered and the command sequence scripted, press the OK 
button as shown in Figure 5.19. 


5. Creating a Tabular Distribution 

The tabular distribution created will be used to model the selection of the file size 
to read on the application server: 

a) Select the Table option from the Define menu, and in the tabular distribution window 
which appears press the Add button. 

b) Edit the fields of the table detail window to the following values. Figure 5.20 depicts 
the table upon completion. 

• Name: Office 

• Table Type: discrete 

• Prob and Values: Set to the cumulative probabilities and file size values of 
Table 5.1. 
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Figure 5.20 Office User Defined Distribution 

c) When all values have been entered press the OK button as shown in Figure 5.20 and 
then press the Done button at the bottom of the tabular distribution window. 

6. Creating the Application Server’s Application Source 

The application source which will run on the application server will be built by 
first defining the commands which will be used in this application, and then creating the 
application source. 

a) Define a local read command on the Application Server node. 

b) Edit the fields of this command to the values of the following list. Figure 5.21 depicts 
the command upon completion. 

• Name: MS Office Read 

• File to Access: GENERAL STORAGE 

• File modification method: Do not modify file 

• Bytes read calculation: Probability distribution 

• Probability distribution: Office 

c) When all fields have been edited, press the OK button at the bottom of the read 
command window; press the Done button at the bottom of the command repertoire 
window; and press the OK button at the bottom of the node detail window. 
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Figure 5.21 MS Office Read Command 


d) Define a global answer command and edit the fields of the answer command window 
to the following list. Figure 5.22 depicts the command upon completion. 



Figure 5.22 MS Office Answer Command 


• Name: MS Office Answer 

• Priority: 1 

• Routing Class: Standard 

• Transport protocol: TCP/IP-Microsoft 

• Packetize: 1.0 milliseconds 

• Message Size Calculation: (A x File Bytes) + B 

• A: 1.000 
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• B: 0.000 

• Message text option: Copy message name 

e) When all fields are edited, press the OK button at the bottom of the answer command 
window, and the Done button at the bottom of the command repertoire window. 

f) Create an application source and place it next to the Application Server node. 

g) Connect the application source to the Application Server node using either connection 
tool. 

h) Edit the application source fields to the following parameters. Figure 5.23 depicts the 
application source upon completion. 

• Name: MS Office Suite 

• Schedule by: Set to the received message option, and create a received 
message list which requires one message with the text “MS Office Request” to 
trigger the application source. 



Figure 5.23 MS Office Suite Application Source 

i) In the command sequence box shown in Figure 5.23 add the following commands set 
to execute a single time. 

1. MS Office Read 

2. MS Office Answer 
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j) When all values and the command sequence have been entered, press the OK button 
at the bottom of the application source window. 


7. Creating the File Server’s File Request Application Source 
The file request application source which will run on the file server will be built 
by first defining the commands which will be used in this application, and then creating 
the application source. 

a) Create a global process command and edit the fields of the process command window 
to the following values: 

• Processing command name: File Request Processing 

• Number of cycles calculated: (A x Msg Bytes) + B 

• A: 1.500 

• B: 0.000 

b) When all values are entered, press the OK button at the bottom of the process 
command window. 

c) Define a global read command and edit the parameters of the read command window 
to the following: 

• Name: File Request Read 

• File to Access: GENERAL STORAGE by default 

• File modification method: Do not modify file 

• Bytes read calculation: Probability distribution 

• Probability distribution: Set to a normal distribution with a mean of 150,000 
bytes and a standard deviation of 50,000 bytes. The stream value may be set to 
any integer value from 0 to 99. 

d) When all values have been entered, press the OX'button at the bottom of the read 
command window. 

e) Define a global answer command and edit the fields of the answer command window 
to the following: 

• Name: File Request Answer 

• Priority: 1 

• Routing Class: Standard 

• Transport protocol: TCP/IP-Microsoft 

• Packetize: 1.0 milliseconds 

• Message Size Calculation: (A x File Bytes) + B 

• A: 1.000 
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• B: 0.000 

• Message text option: Copy message name 

f) When all values have been entered, press the OK button at the bottom of the answer 
command window, and press the Done button at the bottom of the command 
repertoire window. 

g) Create an application source and place it by the File Server node. 

h) Connect the application source to the File server node using either connection tool. 

i) Edit the application source parameters to the values shown in the following list. 
Figure 5.24 depicts the application source upon completion. 

• Name; File Request 

• Schedule by: Set to the received message option, and create a received 
message list for which requires one message with the text “File Request” to 
trigger the application source. 
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Figure 5.24 File Request Application Source 
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j) Edit the command sequence box so that the commands appear in the following order 
with a single execution of each command. 

1. File Request Processing 

2. File Request Read 

3. File Request Answer 

8. Creating the Save File Application Source 

The save file application source which will run on the file server will be built by 
first defining the commands which will be used in this application, and then creating the 
application source; 

a) Define a global write file command and edit the command to the values shown in the 
following list. Figure 5.25 depicts the write command upon completion. 

• Write command name: Save Write 

• File modification method: Update data in file 

• Bytes written calculation: (A x Msg Bytes) + B 

• A: 1.000 

• B: 0.000 



Figure 5.25 Save Write Command 

b) When all fields are set, press the OK button at the bottom of the write command 
window, and then press the Done button at the bottom of the command repertoire 
window. 

c) Create an application source and place it next to the File Server node. 

d) Connect the application source to the File Server node using either connection tool. 
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e) Edit the application source fields to the values shown in the following list. 

Figure 5.26 depicts the application source upon completion. 

• Name: Save File 

• Schedule by: Set to the received message option, and create a received 
message list for which requires one message with the text “Save Request 1” or 
“Save request 2” to trigger the application source. 

• Command sequence: Add only the Save Write command with a single 
execution. 



Received message 




mmifi 




Application Source 




1 GLOBAL 


Save Write 


Figure 5.26 Save File Application Source 


f) When all fields are set, press the OK button at the bottom of the application source 
window. 

9. Verifying and Saving the Model 

The final step in building the model is verifying the logical connections. This is 
accomplished by selecting the Verify Model option from the Simulate menu. Any errors in 
the model must be corrected. Finally, save the model. 
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G. SIMULATION AND CONCLUSIONS 

Three replications within a simulation will be run to analyze the problem. Each 
replication will be 3600 seconds in length to model one hour of network loading. The first 
replication was set to a warmup length of 300 seconds to allow the applications in the 
model to begin generating traffic before statistics were started to be gathered. 

Prior to running the simulation, the following reports were set to gather the 
necessary information on network loading , application run length, and disk information 
of the file server. 

• Link Reports: Channel Utilization and Collision Stats for the 63 Net. 

• Application Run Length: Selected for the Application and File Server nodes. 

After running the simulation, the results of each replication are stored in the files 
report. 1, report.2, and report.3 where the number indicates the replication number. The 
results showed that the average network utilization varied from 0.49 percent in the first 
replication, dropped to 0.35 percent in the second replication, and increased again to 0.51 
percent in the final replication. After looking at the collision statistics and transmission 
delays statistics gathered during the simulation, it was decided that the results of the first 
simulation are biased by the manner of modeling the behavior of the users. The average 
transmission delay did not vary greatly between replications (0.977,0.800, and 0.786 
milliseconds), but the standard deviations did vary greatly (12.620,1.370, and 0.800 
milliseconds). Thus, in the first simulation, the start of several applications at the same 
time caused multiple collision episodes and increased the delay on the network. Better 
results might be obtained by increasing the number of replications as the randomness 
built into the modeling of the user behavior would better model the use of the lab. 

The file and application servers application run lengths showed similar behavior 
of longer delays in the first replication, followed by a decrease in application delays in the 
second replication, but then followed by increased delays in the third replication. Due to 
the effects of greater randomness in the third replication, the results of this replication are 
deemed to be the best estimates. The application server took an average of 30 seconds 
with a standard deviation of 7 seconds to read and transmit the program onto the network. 
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The file server took on the average 4 seconds with a standard deviation of 1 second to 
either save or retrieve a file. 

Overall, better results could be obtained by increasing the number of replications 
which would allow the randomness of the users’ behavior to spread out the requests over 
time. 
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VI. LINKS AND TRAFLINK 


A. INTRODUCTION 

The goal of this chapter is to introduce the various link objects which are available 
in COMNET III to model the physical medium over which messages may be transported. 
In addition, the TRAFLINK HI utility within COMNET HI will be covered. This utility 
allows importing traffic files captured from an actual network into a model. 

B. LINK OBJECTS 

Link objects are used to model both the physical media over which packets are 
transmitted and the framing characteristics which model the data link layer of the OSI 
Reference Model. COMNET HI currently has the capability to model point-to-point, 
polling. Aloha, carrier sense multiple access (CSMA), carrier sense multiple access with 
collision detection (CSMA/CD), and token ring links. 

The general logic that COMNET IH uses to model message traffic on a link is 
performed in the following manner for all types of links. When a message packet on a 
node is ready to be transmitted, the node eventually gains access to the link. The packets 
are then broken down into frames according to the framing characteristics set for the link. 
The model then calculates the transmission delay for the frame across the link based on 
the size of the frame and the transmission rate of the link. If a frame error probability is 
set for the link, a random pull from the distribution used to describe this error is then 
made to determine if the frame will arrive in error and require retransmission. The link is 
then made busy for the transmission delay calculated and a propagation delay which may 
be set for the link. After the frame has incurred these delays, it is considered to have 
arrived at either its destination, if the destination is on the same link, or the next node 
along the frame’s routed path. 

Links may be created by choosing any of the three link types available on the 
toolbar or by selecting the Link option from the Create menu. Editing of a link of any 
type will cause the link detail window shown in Figure 6.1 to appear. The window 
contains fields which allow setting a unique name for the link and specifying the type of 
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link which is to be modeled. Any link created may be switched to a different type of link 
by changing the type field. The parameter field allows selecting any of the predefined 
links available in COMNET III or creating a user defined parameter set by pressing the 
button to the right of the parameter field. The control node field may be used to 
specify a controlling node in the model for contention links such as CSMA, CSMA/CD, 
or aloha link types, and is required to be set for a polling link. As with all objects in 
COMNET ni, information in the form of a constant or statistical distribution may be 
entered concerning the time to failure and time to repair for the link. The current state of 
the link, and a simulation toggle time to change this state, may also be entered. 



Figure 6.1 Link Detail Window 

1. Common Link Parameters 

As with any object in COMNET HI, parameter sets may be defined for each type 
of link. The common fields that apply when defining any link are the ability to assign a 
unique name to the link parameter set, specifying the link’s bandwidth, setting of the link 
framing characteristics, setting a propagation delay, defining a frame error probability, 
and setting a link session limit. 

Framing characteristics are used to model the data link protocols in a network. 
The modeling is not detailed in that the common functions which apply to the data link 
layer such as time outs, link level acknowledgments; and cyclic redundancy checks 
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(CRC) are not modeled [Ref. 2 p. 80]. The framing characteristics are used solely to 
model the frame payload capability and overhead which are used in link delay and 
utilization calculations. The fields that define the framing characteristics are as follows: 

• Frame Minimum: Sets the smallest data payload that a frame may carry. 
Frames which are smaller than this value are padded to the minimum size. 

This value includes the frame overhead bits. 

• Frame Maximum: Sets the upper limit of the data payload of a frame. The 
exception is setting this value to zero which implies there is no upper limit. 
This value includes the frame overhead bits. 

• Frame Overhead: Used to specify the overhead bytes associated with the link 
level protocol. 

• Frame Error Probability: Used to set the probability of a frame arriving in 
error on a link which will require retransmission of the frame. This value may 
be described by a constant or any statistical distribution. 

The propagation delay field which is common to all links is used to model the 
time required for a packet to move between two nodes on a link based on distance. The 
COMNET HI User’s Manual states that this feature should be most commonly used to 
model delays associated with transmissions over long distances such as when modeling 
geographically disbursed nodes in a wide area network or satellite links [Ref 2 p. 98]. 

The bandwidth field associated with each type of link is used to specify the 
transmission rate of the link in kilobits per second. The session limit is used to specify the 
maximum number of connection-oriented sessions which the link may support at a given 
time. When the session limit for the link is reached, additional setup packets generated by 
session sources or application sources will be blocked. 

In addition to the link parameters common to every type of link, the contention 
type links of CSMA, CSMA/CD, and Aloha all allow specifying a retry interval when a 
collision occurs. The retry interval may be set to any of the statistical distributions 
available in COMNET HI or to a binary exponential backoff distribution. The binary 
exponential backoff algorithm is specified by the IEEE for determining the retry times for 
nodes connected to a collision link [Ref 2 p. 69]. The algorithm doubles the retry interval 
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of a frame every time a collision occurs, up to a maximum of 10 times. After the tenth 
collision the retry time remains constant, and frame transmissions are attempted up to the 
retry limit. If the retry limit is exceeded the retry interval used is set by the limit delay. 

2. Aloha Link Characteristics and Parameters 

The Aloha link is used for the modeling of random access radio links where 
random transmission may occur, collisions are detected, and retransmission of collided 
frames occurs. The link allows selecting one of the nodes as a control node to which all 
conununications on the link may be directed. The control node is allocated a contention- 
free channel for transmitting packets to all other nodes in the link. All other nodes on the 
link compete over a single channel for transmission. 

The logic applied when running a simulation for frames on an aloha link is as 
previously described for the general case for all links with the exception that collisions 
may occur on this type of link. Collisions occur when two nodes transmit at the same time 
on the link. As there is no control on the link to prevent this from occurring, upon 
detection of a collision the node waits to attempt retransmission based on the retry 
interval specified for the link. 

The transmission of packets on an Aloha link may be modeled using either 
unslotted or slotted operation. Unslotted operation implies that any node may transmit 
packet frames the instant the frames are ready to be transmitted. Slotted operation is 
similar to a time division multiple access (TDMA) scheme where thfe link is divided into 
time slots of equal duration. The difference between Aloha and TDMA is that instead of 
each node having a dedicated time slot to transmit in, as in TDMA, there is contention for 
each time slot by all nodes on the link. Packets may only be transmitted at the beginning 
of the time slot. Thus, if only one node transmits, a collision will not occur. If multiple 
nodes transmit in the same time slot, a collision will occur and retransmission is 
rescheduled based on the retry interval. 

Editing the parameter set of an Aloha link will cause the Aloha parameter window 
shown in Figure 6.2 to appear. In addition to the common characteristics of all links, the 
following fields may be specified to describe the operation of the link: 
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• Slot width: used to set the duration of each slot in units of milliseconds. A slot 
width of zero is used to model unspotted operation. 

• Control channel: Checking this box allows a control node to be specified in 
the link detail window for the link as shown in Figure 6.1. 

• Transmission Return Rate: Used to set the transmission rate in kilobits per 
second of the control channel. 



Figure 6.2 Aloha Parameters Window 

3. Carrier Sense Multiple Access (CSMA) and Carrier Sense Multiple 
Access With Collision Detection (CSMA/CD) Link Characteristics and 
Parameters 

CSMA and CSMA/CD links are multi-access links which may be used to model 
random access links. Nodes on both types of links first listen to the link to see if it is busy 
prior to transmitting packets. The difference in the modeling of the two link types is that 
CSMA is modeled to detect a collision at the end of a transmission whereas CSMA/CD 
is modeled to detect the collision upon its occurrence. The modeling of the CSMA is not 
true to the actual implementation of this data link protocol as retransmissions are 
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rescheduled based on time outs and not true collision detection. However, the method 
chosen to model a CSMA link is a good approximation. 

The logic applied in the modeling of these links in addition to transmission and 
propagation delays as described by the COMNET HI User’s Manual [Ref. 2 p. 88-89] is 
done in the following manner. A node with packets ready to be transmitted first checks to 
see if the link is busy. If busy, transmission of the packet is deferred until the link 
becomes idle. When the link becomes idle, the packet is transmitted and the link is placed 
in an unsettled state for the time period of the collision window. The link is then placed in 
a busy state for the time period of the transmission delay after which the link becomes 
idle again. If multiple nodes detect the link idle and transmit at the same time, or if a node 
transmits during the collision window, a collision will occur on the link. 

Parameter sets for the CSMA/CD type links are included in the COMNET HI 
library for the IEEE 802.3 CSMA/CD 10Base2, lOBaseS, lOBaseT, and lOBaseS Star 
standards; and for the IEEE 802.3 Ethernet lOBaseS standard. No parameter sets are 
defined in the library for CSMA type links. The editing of the parameters of either type of 
link will bring up the window shown in Figure 6.3. The additional fields which may be 
specified for these links are as follows: 

• Collision window: The time period a link is vulnerable to collision after a 
packet is transmitted from a node defined in units of milliseconds. 

• Jam interval: On CSMA/CD type links, the jam interval models the sending 
of a jamming signal by the link upon the detection of a collision. For CSMA 
type links, the jam interval models the interval from the end of a transmission 
until the sending node learns that retransmission is required. 

• Interframe Gap: The amount of time in milliseconds a node delays the 
transmission of a packet once the link is detected as being idle. 

• Control channel: Checking this box allows selecting a control node in the link 
detail window. 

• Transmission return rate: Specifies the transmission rate of the control channel 
in kilobits per second. 
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Figure 6.3 CSMA or CSMA/CD Parameters Window 


4. Point-To-Point Link Characteristics and Parameters 
Point-to-point links may be used to model the links of a wide area network, 
satellite links, phone lines for modem transmissions from a terminal device, or any 
situation where a dedicated link occurs between two terminals. The point-to-point link is 
modeled to have full duplex capabilities. Frames are multiplexed onto the link in the 
order in which they appear in the link buffer which is defined on the port. The logic 
which is applied to this link type when running a simulation is the general case which 
applies to all links. 

Editing the parameters of this link will cause the point-to-point parameter window 
shown in Figure 6.4 to appear. The additional parameters which may be set in modeling 
the operation of this link for data transmission include setting the number of circuits the 
link is to model, and setting the bandwidth per circuit from nodes X to Y and from Y to 
X. Thus, one point-to-point link may be used to model several actual links to simplify the 
modeling. 
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Figure 6.4 Point-To-Point Parameters Window 

5. Polling Link Characteristics and Parameters 

Polling links were created in COMNET HI specifically to model multi-drop 
telephone lines which have a centralized control node which polls other devices on the 
line [Ref. 2 p. 99]. The link operates in a round-robin order such that the controlling node 
queries or polls each node on the link using a control channel. When polled, a node will 
transmit all packets which are currently ready to be transmitted on the link’s common 
channel. If a node has no packets, the node sends a negative acknowledgment to the 
control node which will then query another node. The transmission of the frames across 
the link is done using the general logic applied to all links when running a simulation. 

Editing the parameters of this link will cause the polling link parameters window 
shown in Figure 6.5 to appear. In addition to the common parameters of all link types, the 
polling link’s operation is specified by the following: 

• Control channel: This box must be checked for a polling link and allows 
selecting the node connected to the link which will act as the controlling node 
in the link detail window. 
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• Transmission return rate: Specifies the transmission rate in kilobits per second 
of the control channel. 

• Poll needed to send: Checking this box specifies that the controlling node 
must also be included in the polling scheme to transmit packets. 

• Poll Delay: Used to model the time in milliseconds required to send a poll 
from the control node to any other node on the link. 

• NAK delay: Used to model the time in milliseconds required for a node to 
send a negative acknowledgment back to the control node. 



Figure 6.5 Polling Link Parameters Window 


6. Token Passing Link Characteristics and Parameters 
Token passing links are used to model the characteristics of the IEEE 802.4 and 
802.5 specifications and the ANSI Fiber Distributed Data Interface (FDDI) standard. As 
such, parameters sets are included in the COMNET in library to model links with 
characteristics of the 1Mbps, 5 Mbps, and MAP 10 Mbps IEEE 802.4 standard; 4 Mbps 
and 16 Mbps IEEE 802.5 standard; and a parameter set to model FDDI operation. 

The modeling of the operation of a token passing link is performed in the 
following manner as defined in the COMNET HI User’s Manual [Ref. 2 p. 106,107]. The 
token passing link sends in round-robin order a token to each node on the link. When the 
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token is received by a node, the node may transmit packets for a time specified by the 
token holding limit. A frame continues to be sent if it is more than halfway transmitted 
when the holding limit time is up. If upon receipt of the token a node has no packets to 
send, the token is passed on to the next node immediately. The logic applied upon 
transmission of a packet is the same as the general case for all links. The token itself is 
not modeled within COMNET HI. It is instead modeled by a time calculation. When a 
node has a packet to transmit, it determines which node currently has the token and the 
amount of time which will pass until it receives the token again. The node then delays for 
the amount of time calculated before sending the packet. 

Additional parameter sets for token passing links may be defined. Editing of these 
parameters will cause the token passing parameters window shown in Figure 6.6 to 



Figure 6.6 Token Passing Link Parameters Window 


appear. The following parameters in addition to the common link parameters may be set 
to define the operation of the link. 

• Token passing delay: The amount of time in milliseconds required to pass the 
token from one node to the next. 
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• Token holding limit: The amount of time in milliseconds a node may hold the 
token and transmit packets. 

C. TRAFLINKIII 

TRAFLINK HI is an interface utility provided within the COMNET in application 
which is used to import message packets captured from an actual network into a model. 
The utility produces an external message file which maps the packets captured in the data 
file to the names of the nodes in the model. When a simulation is run, the packets 
captured are routed across the modeled network from their source to destination. A 
complete description of the method used to import traffic data files is given in Section F 
of this chapter. 

1. Capturing Packets 

The capturing of packets on a network may be performed using either a hardware 
or software packet analyzer. Both methods monitor the transmission of packets across a 
network in a promiscuous mode which implies that all packets on the network are 
captured and stored for later use. COMNET III directly supports importing traffic files 
from the HP NetMetrix network analyzer and the Network General Sniffer LAN 
hardware analyzer. Other packet analyzers may be used to collect data files, but the file 
must be formatted into a text space delimited file and format information entered into the 
TRAFLINK utility in order to create the external traffic file to run in a simulation. 
Important considerations when selecting a traffic analyzer include; 

• The protocols supported by the analyzer. 

• Time stamp precision for capturing packets. 

• The ability of the analyzer to provide the necessary information to import the 
captured data file into COMNET HI. 

• The total number of packets the analyzer is capable of capturing and saving in 
one run without dropping packets. 

In order for a captured data file to be imported into COMNET HI the file must contain the 
following information: 
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• The delta or elapsed time between captured packets. 

• The packet size in bytes. 

• The source or node which generated the packet. 

• The destination of the packet. 

• The packet identity. 

2. Scaling External Traffic Files 

Once an external message file has been created, a scale factor may be applied to 
this external file to represent an increase or decrease in network loading when running a 
simulation. For example, to represent a 40 percent increase in traffic on a network a scale 
factor of 1.4 is used. The traffic is scaled when running a simulation by either shortening 
the delta time between packets to model an increase in network loading or lengthening 
the delta time between packets to model a decrease in network loading. The total number 
of packets in the external file does not change in either case. The implication of using a 
scaling factor with an external file is that the simulation run time will also need to be 
adjusted by the same scaling factor for simulation results to have the greatest accuracy. 

D. PROBLEM STATEMENT 

On February 7, 1996, the Systems Technology Lab’s 10Base2 Ethernet network 
was experiencing excessive delays. In order to determine the cause of these delays the 
protocol analyzer Snoop, which is part of the Sun Solaris release 2.4 operating system, 
was used to capture packets from the network and saved to a file. The desire of the lab 
personnel was to build a model of the network topology and use the data collected to 
determine the network loading and delays at the time the data was captured. 

E. ANALYSIS 

The capturing of packets on the Systems Technology Lab’s ethemet network was 
performed running the Snoop application on a Sun Sparc 20 workstation. The Snoop 
protocol analyzer was chosen to capture packets as it was the only protocol analyzer 
application available in the Systems Technology Lab, and it provided the necessary 
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information for importing a data file into COMNET HI. The command used to capture the 
packets was as follows: 

snoop -d lei -s 34 -c 2000 -o /tmp/lnet63 -t d -S 
This string entered in the UNIX command window is interpreted as follows [Ref. 6]: 

• snoop: Start the snoop application 

• -d lei: Capture packets from the ethemet network 

• -s 34: Truncate each packet so that only the first 34 header bytes are saved 

• -c 2000: Capture 2000 packets 

• -o /tmp/lnet63: Save packets captured to the file lnet63 

• -t d: Use the delta time between packets as the time step 

• -S : Record the total length in bytes of each packet 

Only 2000 packets were captured as previous attempts to capture 10000 and 5000 packets 
resulted in core dumps of the workstation. This was later determined to have been caused 
by inadequate disk space on the workstation to write the packets as they were captured. 
The decision to truncate the packets was made to reduce the amount of data which would 
need to be written to a file and to minimize the chance of dropping packets while writing 
to the disk which results in gaps of lost packets. The second problem had been shown to 
happen in previous experimentation with the application when the entire packet was 
saved. 

In order to convert the data file saved to a form which was palatable for 
COMNET in, the file was first converted from a binary format to a text format. This text 
file was then edited using a spreadsheet application to remove extraneous information and 
to provide only the data needed within COMNET HI of source, destination, length, time 
stamp, and a unique identifier for which the protocol identifier was used. The file was 
saved in the text space-delimited (*.pm) format required for COMNET IH. A word 
processing program was then used to determine column start points in the file in order to 
be able to describe the format of the file to the TRAFLINK utility. The packets captured 
were also looked at to determine the total amount of time over which packets were 
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captured to set the simulation and the nodes these packets were routed which is needed to 
build the model topology. 

F. BUILDING THE MODEL 

This section gives step-by-step instructions for each object which will be created 
in making the model used to analyze the problem statement. Figure 6.7 displays a view of 
the model topology upon completion. 



1. Creating the Network Links 

The two networks which make up the Systems Technology Lab will first be 
created to model the 10Base2 ethemet network and FDDI networks located in the lab 

a) Create a collision and token passing link in the workspace. 

b) Edit the collision link to the following parameters in the link detail window: 

• Name: 63 Net 

• Type: CSMA/CD 

• Parameters: 802.3 CSMA/CD 10BASE2 

c) At the bottom of the link detail window press the Statistics button and edit the list so 
that the observations are saved and statistics are gathered for both the Contention 
Channel Utilization and Contention Channel Transmission Delay options in the list. 
When these options are set, clear the link detail window by pressing the OK button. 


126 







d) Edit the token passing link to the following parameters in the link detail window: 

• Name: 64 Net 

• Type: Token passing 

• Parameters: FDDI 

e) At the bottom of the link detail window press the Statistics button and edit the list so 
that the observations are saved and statistics are gathered for both the Utilization and 
Transmission Delay options in the list. When these options are set, clear the link 
detail window by pressing the OK button. 

2. Creating the Computer Parameter Set 

The computer and communications node parameter set that is defined will be used 
to represent the nodes on both networks. Since no applications will be defined in this 
model, only the port processing delays will be modeled. 

a) Define a computer and communications node parameter set using the Node/Computer 
and Communication option on the Define menu. 

b) Press the Add button in the computer and communication parameters window which 
appears, and edit the following fields in the node parameter window: 

• Name: STL Workstation 

• Port processing default time: 0.05 milliseconds for both the input and output 
buffers 

c) Press the OK button in the node parameters window and the Done button in the 
computer and communications node parameters window to clear these windows. 

3. Creating a T1 Point-To-Point Link 

The T1 point-to-point link will be used to model the connection of the FDDI 
network to outside sources. 

a) Create a point-to-point link and place it in the vicinity of the 64 Net link. 

b) Edit the point-to-point link fields in the link detail window to the following: 

• Name: T1 Link 

• Type: Point-to-point 

• Parameters: T1 
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c) When all fields are entered, press the OK button at the bottom of the link detail 
window. 


4. Creating the Network Nodes 

The review of the data captured revealed that packets were captured from seven 
nodes on the network. Several sources outside the network were also captured. These 
sources will be modeled as all coming from a single node connected to the T1 link, 

a) Create and edit eight computer and communications nodes so that the fields in the 
node parameters window for each is set to the values shown in Table 6.1. After 
creating and editing each node, attach the node the link(s) also defined in Table 6.1. It 
is important that the node names are typed as explicitly shown for later matching 
names when creating the external traffic file for the model. 


Node Name 

Type 

Parameters 

Link 

Cadet 

C&C Node 

STL Workstation 

64 Net 

Navy 

C&CNode 

STL Workstation 

64 Net 

Cornflower 

C&C Node 

STL Workstation 

63 Net 

Lime 

C&C Node 

STL Workstation 

63 Net 

Marine 

C&C Node 

STL Workstation 

63 Net 

Cirrus 

C&C Node 

STL Workstation 

63 Net 

Azure 

C&C Node 

STL Workstation 

63 Net & 64 Net 

Internet 

C&C Node 

STL Workstation 

T1 Link 


Table 6.1 Computer and Communication Nodes Parameters 


b) Create a router node and edit the fields in the node detail window to the following: 

• Name; Router 

• Type: Router 

• Parameters: Proteon DNX 300, V 12.0 

c) Connect the router node to both the T1 Link and the 64 Net link 

d) The network topology is now defined. Save the model at this time. 


5. Creating the Model’s External Traffic Source 
The following steps describe the manner in which the TRAFLINK HI utility 
creates the external message file from the captured network traffic: 
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a) From the Define menu select the External Trajfic/Messages option. The window 
shown in Figure 6.8 will then appear. 



Figure 6.8 External Messages Window 

b) Press the Create Ext File with TRAFLINK III button and the window shown in Figure 
6.9 will appear. 



Figure 6.9 TRAFLINK HI Setup Dialog Window 

c) Using the button with double dots on it at the end of historical traffic file field, select 
the file stlS.prn. 

d) Check that the automatic name match box is checked. 

e) Select custom for the historical file layout and then press the double dot button to the 
right of the custom option. A window as shown in Figure 6.10 will then appear which 
allows setting the information needed for TRAFLINK HI to read the data file. 

f) Edit the fields on fields shown in Figure 6.10 to the following: 

• Source Start: 17 

• Source Length: 20 
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• Destination Start: 41 

• Destination Length: 20 

• Message/ID Start: 65 

• Message/ID Length: 3 

• Time Start: 9 

• Time Length: 8 

• Size: 73 

• Overhead per Message: 0 

• Ignore Lines Containing fields: All fields cleared 

• Time in Hours Minutes Seconds box: Not checked 



Figure 6.10 TRAFLINK HI Historical File Layout Window 


g) When all fields have been edited press the Save Profile button to save the profile 
entered for later use. This creates a .pro file which may be reloaded if needed at a later 
time using the Load Profile button. The completed historical file layout window 
should now appear as shown in Figure 6.11. 
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Figure 6.11 Historical File Layout for the File stl3,prn 

h) Press the Close button shown at the bottom of Figure 6.11 to return to the 
TRAFLINK HI Setup Dialog window shown in Figure 6.9. 

i) Press the Load Historical File button shown in Figure 6.9. The TRAFLINK HI utility 
will then scan the file to match the names of sources and destinations in the file to 
those of the model and determine the message identifiers found in the file. If names in 
the file are not matched, the window shown in Figure 6.12 will appear. 



Figure 6.12 TRAFLINK III Message Box 

j) Press the Continue button shown in Figure 6.12. The window shown in Figure 6.13 
will then appear. The lower portion of this window contains a list of all names found 
in the external data file, and the names they were matched with in the model if the 
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display matched names box is checked. The replace selected names box allows 
assigning multiple external sources to a single node within a model. 

k) When building this model, the external source name “131.120.7.105” was not 
matched. Single clicking on this name will cause the window shown in Figure 6.14 to 
appear. 

l) The external source “131.120.7.105” is outside of the network being modeled. The 
node named “Internet” was created in the model for any traffic captured which was 
generated by outside sources. Select the “Internet” node shown Figure 6.14 with a 
single click and then press the O/T button at the bottom of the window. 

m) Press the Save LNK File button at the bottom of Figure 6.13. This creates a file with a 
.Ink extension which may be reloaded if needed at a later time using the Load LNK 
File button at the bottom of the same window. 



132 




















Figure 6.14 TRAFLINK III Name Matching Window 

n) Press the Save EXT File button as shown at the bottom of Figure 6.13. The 
TRAFLINK HI utility will then perform two passes over the data file, and will 
generate a file called message.ext which is saved to the same path as the model file 
was saved. This file will be used to generate the external traffic when running a 
simulation. If additional traffic files are needed, they may be added to the message.ext 
file by specifying a new historical file and following the instructions outlined in steps 
c through n above. 

o) Press the Close button at the bottom TRAFLINK IQ setup dialog window. 

p) In the external messages window, check the use external file box, set the traffic scale 
to 1.000, and press the Done button. 

q) Verify and save the model. 

G. SIMULATION AND RESULTS 

The amount of time packets were captured amounted to 3.3 seconds of data. As 

such, the simulation run time should be set to 3.3 seconds. Prior to running the simulation 

select the following reports; 

• Node Reports: Received Message Counts for all nodes 
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• Link Reports; Channel Utilization for all links in the model 

• Message and Response Source Reports: Message Delay for all nodes 

The reports generated after running the simulation calculated the utilization of the 
ethernet network to be at 9.2 percent as an average for the 3.3 seconds of simulation time, 
and an average transmission delay of 0.191 milliseconds. Plots of the link utilization and 
delay which are shown in Figures 6.15 and 6.16 respectively over the simulation time 
interval were produced by plotting the observations saved for the ethemet link. These 
plots indicated the transmission delay to be falling off from the beginning to the end of 
the data captured and the utilization demonstrates the burstiness of traffic on the network. 

The utilization and delays calculated by the model seemed to be less than those 
experienced on the network the day the data file was captured. The message delays for 
message and response sources does indicate which nodes were generating the majority of 
the traffic on this day. By investigating who was running which application on what 
workstation the problems with the network were discovered. One problem was caused by 
a student running the MATLAB application on an SGI Indy workstation named 
Cornflower which was generating large numbers of file requests to the file server named 
Navy. In addition, a professor using the workstation named Cirrus had established an 
MB ONE session where a large number of multicast UDP packets were sent across the 
network. The student was asked to run the MATLAB application during the evening to 
minimize the effects on the network. 
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Figure 6.15 Ethernet Utilization 
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Figure 6.16 Ethernet Transmission Delay 
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VII. ROUTERS 


A. INTRODUCTION 

The goal of this chapter is to introduce the characteristics and parameters 
associated with the router node in the COMNET III application. A network model 
describing the use of a router in the segmentation of a local area network will be used to 
demonstrate the use of the router node. 

B. ROUTER NODES 

The router node was developed in the COMNET IQ application to allow the 
modeling of router-based networks in a packet switched environment. The node was 
designed to model network hardware such as routers, hubs, and bridges. When modeling 
a router node, the premise used is that the performance of the node may be described by 
the input and output buffering characteristics of the node and its internal switching rate 
[Ref. 2 p. 135]. In actuality, the router node is a computer and communications node 
which has the additional characteristic of modeling the transmission rate of the node’s 
internal bus for switching packets. 

Router nodes may be connected to any type of link available in COMNET HI. 
Each link connected to the node is modeled as having its own port corresponding to a line 
card in the node. Editing of each port attached to the node allows entering a line card 
identification. Ports having the same non-blank line card identification are modeled as 
being connected to the same line card in the node. Packets which are routed through the 
same line card in the node will not incur a bus transfer delay as they will not have to be 
switched across the nodes internal bus. Ports having different or blank line card 
identification require switching across the internal bus when routing decisions are made 
within the node. 

The logic applied when routing packets through a router node in a simulation is 
performed in the following manner. When all frames which make up the packet arrive at 
the node, the packet is attempted to be placed in the node’s input buffer. Tests are 
performed in the same manner as for a computer and communications node to determine 
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if there is space in the port buffer and that the total buffer capacity of the node is not 
exceeded. If the packet is accepted, it is placed in the input buffer based on its priority 
and ordered in first-in-first-out order. The packet will then undergo the port processing 
delay after which it is eligible to be switched across the node’s internal bus if it needs to 
be routed to a different line card. The switching is modeled as a time delay which is based 
on the size of the packet to be switched and the transmission rate of the internal bus. The 
choice of which packet is to be switched across the bus is made by determining which 
packets have waited the longest in the various input buffers. Once the packet h^ been 
switched, it is attempted to be placed in an output buffer. Tests are performed again to 
determine if the output buffer capacity and the total node capacity will be exceeded as 
with the input buffer. The packet then undergoes an output port processing delay prior to 
being transmitted. 

Router nodes may be created by using either the toolbar or the Create menu. 
Editing of the parameters of a router node will cause the window shown in Figure 7.1 to 
appear. The fields used to define the modeling characteristics of the router node are the 
same as the computer and communications node with the following exceptions: 

• Bus rate: Specifies the node’s internal bus transmission rate. 

• Bus count: Specifies the number of packets which the node may switch 
simultaneously. 

The COMNET III library contains parameter sets for various commercial routers 
built into the system library. The values used to define the operating characteristics of 
these parameter sets are based on tests performed at the Harvard Network Device Test 
Laboratory. The tests run at this laboratory generally consist of routing a packet stream 
through the device and measuring the buffer and switching delays of the device. Several 
tests are performed where the packet protocol and packet size are varied between tests. 
The delays measured in each run are then averaged to provide the delay characteristics of 
the router. 
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Figure 7.1 Router Parameters Window 

C. PROBLEM STATEMENT 

The utilization of the Systems Technology Lab’s 10Base2 ethemet network is 
estimated to increase by a factor of 3.5 within the next two years based on the probability 
of additional computers being placed on the network and the use of computers currently 
on the network for thesis research or processing. The lab manager also believes the use of 
multicast backbone (MBONE) utilities avjulable in the laboratory will increase in use as 
desktop video conferencing becomes a more prevalent method of performing thesis 
research. There are currently four workstations available to students throughout the lab 
which have desktop video conferencing capabilities. It is estimated that only two would 
be used for this purpose at a single time. 

The lab personnel desires a model to be built to estimate the network utilization 
and delays based on the current network configuration. Also, the lab would like a 
proposal of a method to segment the ethemet network into two separate networks by 
using a router. 
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D. ANALYSIS 

Three pieces of information are needed to construct the traffic generators which 
will be used in a model to analyze the problem. The first is an estimate of the network 
loading on the ethernet network. The second piece of information is an understanding of 
how the multicast backbone operates in a loca:i area network. The third piece of 
information needed is estimates of the size and interarrival time of packets generated 
when using desktop video conferencing tools over the network. 

To obtain the estimate of current network loading, the protocol analyzer Snoop 
was again used to capture packets from the ethernet network. 10000 packets were 
captured from the ethernet network on April 3,1996. Of these packets, 9136 provided the 
information necessary for importing into COMNET HI using the TRAFLINK III utility. 
The total length of time over which the packets were captured was 110 seconds. The data 
file captured was converted to a text space delimited format using a spreadsheet 
application. Also, a list was made of nodes from which packets were captured for 
reference in building the model. 

A Silicon Graphics Indy workstation (Cadet) is used as the multicast router on the 
System Technology Lab’s ethernet network. All multicast packets generated using a 
MBONE utility are directed to the multicast router. The multicast router then broadcasts 
the packet to all nodes on the network. For transmission to another network, the multicast 
router will encapsulate the multicast packets to appear to be unicast packets using the 
UDP/IP protocol to routers along the path to the other network. In order to rnodel this 
process, a message source using received message scheduling may be used. Upon receipt 
of a multicast packet, the message source will broadcast the identical message received to 
all nodes on the network using a multicast list. 

To gather the necessary information of packet size and interarrival times for 
desktop video conferencing, the MBONE application NetVideo was used. A desktop 
video conference was established on the ethernet network using the NetVideo application. 
The application was set to deliver packets at a transmission rate of 128 kbps which is the 
expected transmission rate of video on the multicast backbone [Ref. 7 p. 3]. The Snoop 
application was again used and was set to capture packets only generated by the 
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workstation used to establish the video conference session. A total of 4000 packets were 
captured from the workstation of which 3148 were determined to be multicast packets 
generated from the NetVideo application. This determination was made by reviewing the 
identity of the protocol of each packet and discarding packets that did not use the UDP/IP 
multicast protocol. 

From the data captured, the goal was to be able to describe the packet size and 
interarrival time as a statistical distribution which could then be used in a message source 
to model video conferencing across a network. The histogram shown in Figure 7.2 
displays the frequency of packet size for the packets sorted into bins of 10 byte widths. 
The histogram shown in Figure 7.3 displays the frequency of the interarrival times for 
packets sorted into bins of 0.01 seconds in width. Neither histogram implied that the 
data collected could be modeled using one of the statistical distributions available 
in COMNET HI, so the decision was made to model the interarrival times as discrete 
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Figure 7.2 Packet Size Histogram 
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Packet Ddte Time (seconds) 


Figure 7.3 Packet Interarrival Time Histogram 


tabular distributions. Table 7.1 displays the packet size, probability, and cumulative 
probability which will be used to create a tabular distribution for modeling the packet 


Packet Size (bytes) 

Probability 

Cumulative Probability 

20 

0.03 

0.03 

50 

0.01 

0.04 

340 

0.07 

0.11 

1050 

0.13 

0.24 

1060 

0.17 

0.41 

1070 

0.13 

0.54 

1080 

0.11 

0.65 

1090 

0.09 

0.74 

1100 

0.08 

0.82 

1110 

0.06 

0.88 

1120 

0.04 

0.92 

1130 

0.03 

0.95 

1140 

0.02 

0.97 

1150 

0.01 

0.98 

1160 

0.01 

0.99 

1170 

0.01 

1.00 


Table 7.1 Packet Size and Probabilities 
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size. Data which sorted into a bin having a probability less than 1 percent was not 
included in the modeling of the packet size. Table 7.2 displays the packet interarrival 
time, probability and cumulative probability which will be used to create the tabular 
distribution for modeling the packet interarrival time. Data which sorted into a bin having 
a probability less than 0.1 percent was not included for modeling. 


Packet Interarrival Time (seconds) 

Probability 

Cumulative Probability 

0.01 

0.022 

0.022 

0.02 

0.015 

0.037 

0.03 

0.018 

0.055 

0.04 

0.076 

0.131 

0.05 

0.052 

0.183 

0.06 

0.107 

0.290 

0.07 

0.294 

0.584 

0.08 

0.172 

0.756 

0.09 

0.022 

0.778 

0.10 

0.008 

0.786 

0.11 

0.012 

0.798 

0.12 

0.008 

0.806 

0.13 

0.046 

0.852 

0.14 

0.069 

0.921 

0.15 

0.025 

0.946 

0.16 

0.005 

0.951 

0.17 

0.002 

0.953 

0.18 

0.004 

0.957 

0.19 

0.003 

0.960 

0.20 

0.015 

0.975 

0.21 

0.015 

0.990 

0.22 

0.002 

0.992 

0.25 

0.001 

0.993 

0.26 

0.003 

0.996 

0.27 

0.002 

0.998 

0.28 

0.002 

1.000 


Table 7.2 Packet Interarrival Times and Probabilities 


The final problem to consider prior to building the model is determining a method 
of segmenting the ethernet network. The method chosen was to segment the network 
according to the workstations which are capable of desktop video conferencing and those 
which are not. The reason this method was chosen is due to the manner in which the 
multicast router broadcasts packets to all nodes on a network and the relatively high 
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bandwidth required for video conferencing over a network. Segmentation of the network 
in this manner would isolate the other network from all MBONE applications. 

E. BUILDING THE MODELS 

This section outlines the steps required to build the two models which will be 
used to analyze the problem in an object-by-object manner. Upon completion of building 
the two models, they should appear similar to the model topologies shown in Figure 7.4 
for the current network topology and Figure 7.5 for the proposed changes. 
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1. Creating the Network Links 

The following steps outline the procedure for creating the links which will be used 
in modeling the network.: 

a) Create a collision link, token passing link, and a point-to-point link. 

b) Edit the fields in the link detail window of the collision link to the following: 

• Name; 63 NET 

• Type: CSMA/CD 

• Parameters; 802.3 CSMA/CD 10BASE2 

c) Press the Statistics button at the bottom of the link detail window, and set the 
contention channel utilization option so that observations are saved and statistics are 
gathered when running a simulation. 

d) Edit the fields in the link detail window for the token passing link to the following : 

• Name: 64 NET 

• Type; Token passing 

• Parameters: FDDI 

e) Edit the link detail window for the point-to-point link to the following values: 
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• Name; T1 Link 

• Type: Point-to*Point 

• Parameters: T1 

2. Creating the Network Nodes 

The nodes which are defined in the network are based on the names captured in 
the data file which will be used to define the external traffic. It is important to name the 
nodes as explicitly written to allow the name matching to be performed correctly when 
running the TRAFLINK HI utility. The parameter set which will be used for the computer 
and communications node is modeled using only the default port processing times. This 
choice was made as only this attribute of the node affects the traffic generated by the 
external file and modeled message sources. 

a) Define a computer and communications node parameter set and edit the following 
fields in the node parameters window: 

• Name; STL Workstation 

• Port Processing Default Time: 0.05 milliseconds for both the input and output 
buffers. 

b) Create 26 computer and communications nodes (C&C nodes). Edit the fields of the 
node detail window to those shown in Table 7.3. Connect the nodes to the link(s) 
specified in Table 7.3. When creating the C&C nodes, group the first five nodes listed 
in Table 7.3 in the same area in the work space. 

c) Create a router node and connect it to the T1 and 64 NET links. Edit the fields in the 
node detail window for the router to the following: 

• Name: FDDI ROUTER 

• Type: router 

• Parameters: Proteon DNX 300, V12.0 
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Node Name 

Type 

Parameters 

Link 

CADET 

C&C Node 

STL Workstation 

63 NET 

CORNFLOWER 

C&C Node 

STL Workstation 

63 NET 

CIRRUS 

C&C Node 

STL Workstation 

63 NET 

PERIWINKLE 

C&C Node 

STL Workstation 

63 NET 

TEAL 

C&C Node 

STL Workstation 

63 NET 

POPS 

C&C Node 

STL Workstation 

63 NET 

BLUE-DHRSC 

C&C Node 

STL Workstation 

63 NET 

WHITE 

C&C Node 

STL Workstation 

63 NET 

MARINE 

C&C Node 

STL Workstation 

63 NET 

TANGERINE 

C&C Node 

STL Workstation 

63 NET 

TAUPE 

C&C Node 

STL Workstation 

63 NET 

ZOOM 

C&C Node 

STL Workstation 

63 NET 

FLETCH 

C&C Node 

STL Workstation 

63 NET 

BABY 

C&C Node 

STL Workstation 

63 NET 

HOUND 

C&C Node 

STL Workstation 

63 NET 

CYAN 

C&C Node 

STL Workstation 

63 NET 

JADE 

C&C Node 

STL Workstation 

63 NET 

LIME 

C&C Node 

STL Workstation 

63 NET 

ROYAL 

C&C Node 

STL Workstation 

63 NET 

TURQUOISE 

C&C Node 

STL Workstation 

63 NET 

ROSE 

C&C Node 

STL Workstation 

63 NET 

TRUES 

C&C Node 

STL Workstation 

63 NET 

AZURE 

C&C Node 

STL Workstation 

63 NET & 64 NET 

NAVY 

C&C Node 

STL Workstation 

64 NET 

SPOT 

C&C Node 

STL Workstation 

64 NET 

THE INTERNET 

C&C Node 

Default 

T1 LINK 


Table 7.3 Computer and Communication Node Parameters and Links 


3. Creating the Tabular Distributions 

The tabular distributions created will be used to describe the message size and 
interarrival times of the NetVideo message source. 

a) From the Define menu select the Tables option. 

b) Press the Add button in the tabular distributions window, and edit the fields of the 
table detail window to the following: 

• Name: NVSIZE-TAB 

• Table type: discrete 

• Probabilities and Values: Enter the cumulative probabilities and packet size 
from Table 7.1 into the probability and values fields respectively. 
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c) When all fields are entered, press the OK button at the bottom table detail window. 
Then, press the Add button in the tabular distributions window to create the second 
distribution. 

d) Edit the fields of the table detail window to the following: 

• Name: NVINTER-TAB 

• Table type: discrete 

• Probabilities and Values: Enter the cumulative probabilities and packet size 
from Table 7.2 into the probability and values fields respectively. 

e) When all fields are entered, press the OK button at the bottom table detail window. 
Then, press the Done button in the tabular distributions window to create the second 
distribution. 


4. Creating the NetVideo Message Source. 

The NetVideo message source will be used to model the broadcast of multicast 
packets for desktop video conferencing. 

a) Create a message source and edit the fields of the message source window to those 
shown in the following list. Figure 7.6 depicts the message source window upon 
completion. 

• Name: NET VIDEO 

• Schedule by: Iteration time 

• Interarrival: NVINTER-TAB 

• Message size calculation: Probability distribution 

• Probability distribution: NVSIZE-TAB 

• Priority: 1 

• Routing class: Standard 

• Transport protocol: UDP/IP-Sun 

• Packetize: 0.5 milliseconds 

• Message text option: Copy message name 

• Destination type: Set to weighted list and create a list containing only the node 
CADET. 
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Figure 7.6 NetVideo Message Source 

b) When all fields have been entered press the OK button at the bottom of the message 
source window. 

c) Create a copy of the NET VIDEO message source. 

d) Attach one copy of the message source to the node PERIWINKLE and the other to the 
node TEAL. 

5. Creating the Multicast Router Message Source 

The multicast router message source is used to model the broadcast of packets to 
all nodes on the network upon receipt of a message from the NetVideo message source. 

a) Create a message source and connect it to the node CADET. 

b) Edit the fields of the message source window to those shown in the following list. 
Figure 7.7 depicts the message source window upon completion. 

• Name: MBONE ROUTING 

• Schedule by: Set to received message and use the Edit Received Messages 
button so that the receipt of one message with the text NET VIDEO will 
trigger the message source. 

• Message size calculation: (A x Msg bytes) + B 

• A: 1.000 
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• B: 0.000 

• Priority: 1 

• Routing class: Standard 

• Transport protocol: UDP/IP-Sun 

• Packetize: 0.5 milliseconds 

• Message text option: Copy message name 

• Destination type: Set to multicast list and create a list containing all nodes 
except CADET, NAVY, FDDI ROUTER, and SPOT. 



Figure 7.7 MB ONE ROUTING Message Source 


c) Save the model at this time using the name Inet63.c3. 

6. Deflning the External Message Traffic 

The external message traffic will be created using the TRAFLINK HI utility to 
model the network loading. 

a) Select the External Traffic/Messages option from the Define menu. In the external 
messages window which appears press the Create Ext File with TRAFLINK III 
button. 
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b) In the TRAFLINK EU setup dialog window define the path to the file lnet63.prn in 
the historical traffic file field. Then, select the custom option for the historical file 
layout and press the double dot button next to the custom option. 

c) Edit the fields in the TRAFLINK HI historical file layout window to the following 
values. Figure 7.8 depicts the window upon completion. 

• Source Start: 17 

• Source Length: 20 

• Destination Start: 41 

• Destination Length: 20 

• Message/ID Start: 65 

• Message/ID Length: 8 

• Time Start: 9 

• Time Length: 8 

• Size: 77 

• Hold/Call: 0 

• Overhead Per Message: 0 

• Ignore lines containing: All fields empty 

• Time units: Seconds 

• Time in hours minutes seconds box: Not checked 

d) When all values have been entered use the Save Profile button to save the file using 
the name lnet63.pro. This file may be later reloaded if needed to describe the layout 
of the file lnet63.prn. After completion of saving the layout file, press the Close 
button in the TRAFLINK IE historical file layout window. 

e) In the TRAFLINK IE setup dialog window press the Load External File button. The 
program will perform a first pass of the traffic file to match names in the model to the 
names in the file. Upon completion of the first pass a window should appear which 
states that 15 external names were not matched. Press the Continue button in this 
window. 

f) In the TRAFLINK IE name linking window which appears, check the replace selected 
names box and deselect the display matched names box. The external names list will 
now contain only those names which were not matched. Match the external name 

131.120.63.255 to the node named WHITE. Match all other external names to the 
node named THE INTERNET. 
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Figure 7.8 Historical File Layout for the File lnet63.pm 

g) When all external file names are matched press the Save LNK File button and save the 
file using the name lnet63.1nk. Then, press the Save EXT file button. The 
TRAFLINK HI utility will then perform two passes of the historical file and create a 
file called message.ext which will be saved in the directory lnet63. 

h) Press the Close button in the TRAFLE^K III setup dialog window. Then, check the 
use external file box; set the traffic scale to 3.5; and press the Done button in the 
external messages window. 

i) The first model is now complete. Verify and save the model Inet63.c3 again. 

7. Creating the Second Model 

The following steps describe the method of changing the first model produced to 

create the proposed changes to the network. 

a) Use the Save As option from the File menu to save the file Inet63.c3 using the name 
Inet63a.c3. 
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b) Check that the file Inet63a.c3 is the file currently being modified, clear the ports 
connecting the nodes CADET, CORNFLOWER, CIRRUS, PERIWINKLE, TEAL, 
and AZURE to the 63 NET link. 

c) Make a copy of the 63 NET link, and rename the link SEG 63 NET. Attach the nodes 
CADET, CORNFLOWER, CIRRUS, PERIWINKLE, and TEAL to this new link. 

d) Make a copy of the FDDI ROUTER node, and rename the node SEG ROUTER. 
Connect this node to the 63 NET, SEG 63 NET, and 64 NET links. 

e) Edit the MBONE ROUTING message source destination list such that the multicast 
list contains only the following nodes in the list: TEAL, CORNFLOWER, CIRRUS, 
PERIWINKLE, and THE INTERNET. 

f) When the file Inet63a.c3 was created, all parts of the file Inet63.c3 were included 
except the external message file message.ext. The external message file may either be 
recreated using the TRAFLINK IE utility, as before, or copied from the directory 
lnet63 into the directory lnet63a. 

g) The second model is now completed. Verify and save the model. 

F. SIMULATION AND RESULTS 

One simulation for each model will be run to gather results. For both models the 
simulation run time should be set to 30 seconds. This value is used as the external file 
contained 110 seconds of captured data, and the scale factor of 3.5 used in both models 
will reduce the time to approximately 30 seconds. Prior to running each simulation select 
the following reports to be generated at the completion of the simulation for each model. 

• Link Reports: Channel Utilization for the 63 NET and SEG 63 NET links. 

• Nodes: Received Message Counts for all nodes. 

• Message and Response Sources: Message Delays for all nodes. 

The simulation run using the current network configuration showed an overall 
network utilization of 17 percent for the ethemet network, with an average transmission 
delay of 1.6 milliseconds. Figure 7.9 depicts the network utilization over the simulation 
time period. 
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Figure 7.9 Current Network Configuration Utilization 

The simulation ran for the model of the proposed changes showed a network 
utilization of 2 percent for the original ethemet network with a delay of 0.9 milliseconds. 
The proposed new network showed a utilization of 14 percent with the same delay. Figure 
7.10 and Figure 7.11 depict the network utilization for the original network and the new 
network under the proposed changes respectively. 

The method proposed to alter the System Technology Lab’s ethemet network does 
provide one way of isolating the existing network from the volume of traffic generated by 
video teleconference packets created by the workstations and the multicast router. This is 
just one proposed plan of action. Other methods, such as moving the desktop video 
conferencing capable computers to the higher bandwidth FDDI network or a different 
method of segmenting the ethemet network, would need to be analyzed prior to making a 
change in the current network configuration. 
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Figure 7.10 Original Ethernet Network Utilization With Proposed Network Changes 



Figure 7.11 Segmented Ethernet Network Utilization Under Proposed Network Changes 


155 











































VIII. MODELING WIDE AREA NETWORKS 


A. INTRODUCTION 

The goal of this chapter is to introduce the objects available within COMNET HI 
that may be used to model wide area networks (WANs). Specifically, the ATM switch 
node, subnetworks, the wide area network (WAN) cloud, and the routing protocols 
available will be covered. A model of a frame relay WAN used as a portion of the 
multicast backbone will be modeled using the WAN cloud object and by building the 
WAN piece-by-piece using switches and point-to-point links. 

B. ATM SWITCH NODES 

The ATM switch node is aimed at modeling switches, hubs, or routers which have 
a high bandwidth internal switching structure resulting in no contention in switching 
packets across the switch’s bus [Ref. 2 p. 118]. The ATM node is described in COMNET 
ni only by its port buffering characteristics. When a packet enters the buffer of this node, 
it incurs a port processing delay in the same manner as for a computer and 
communications node or a router node. The frame is then switched to an output buffer 
instantaneously with parallel switches between different ports allowed. The difference 
between an ATM node and other nodes available in COMNET IE is its non-blocking 
characteristic. When a packet is switched from an input to an output buffer, the checks 
that the output buffer and total buffering capacity of the ATM switch node are made in 
the same manner as with a router or computer and communications node. However, if this 
test fails, the ATM node will not block the packet. It instead stores the packet until room 
is available in the output buffer the packet needs to be routed. 

The ATM node may be created from either the toolbar or from the Create menu. 
As many links as desired and all types of links may be connected to the node. The ATM 
node may only act as a switching point for traffic and may not be used as the destination 
or origin of traffic. Editing of the node will cause the window shown in Figure 8.1 to 
appear. The fields used to describe the operating characteristics of the node have the same 
meaning as for a computer and communications or router node. 
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Figure 8.1 ATM Parameters Window 


C. SUBNETWORKS 

The subnetwork provides two functions within COMNET El. The first is a 
method of managing the display of a large network. The second is providing a method to 
allow different routing protocols to be used in different portions of the network model. 

A subnetwork is created by choosing the subnetwork icon from the toolbar. 
Maneuvering about a subnetwork is done in a different manner than other objects in 
COMNET in. To edit the name or routing protocol used in the subnetwork, the 
subnetwork icon must first be selected with a single click of the mouse button. Then, 
choosing the Detail option from the Edit menu will cause the window shown in Figure 
8.2 to appear. This window allows specifying the name of the subnetwork and the routing 
protocol which will be used in the subnetwork. The traffic scale field provides a method 
of scaling the traffic generated by all nodes built within the subnetwork without having to 
individually edit each application command or traffic source. The amount of time 
between routing table updates for the nodes in the subnetwork may also be specified. 
Double clicking on the subnetwork icon or selecting the icon and then choosing the Enter 
option from the Edit menu will cause a clear work area to appear. The portion of the 
network which is to be modeled at the subnetwork level is in this area. To return to the 
higher level, which is called the backbone view, either double click in the work area or 
select the Leave option from the Edit menu. 

A subnetwork is connected to the backbone view by means of an access point 
which is created using the toolbar. A minimum of one access point is required within the 
subnetwork. Each access point created may be connected to only one node in the 


158 






















subnetwork. The access point acts as an extension of the node it is connected to and 
allows a link in the backbone view to be connected to the subnetwork. After an access 
point is created and after leaving the subnetwork view, the subnetwork icon in the 
backbone view will have a dot on the edge of the icon for each access point created. This 
is the point where links in the backbone view are connected to the subnetwork. 



Figure 8.2 Subnetwork Detail Window 


D. WIDE AREA NETWORK (WAN) CLOUDS 

The WAN cloud provides an abstract method of modeling wide area networks 
which provides an alternative to modeling a WAN explicitly using router nodes, ATM 
switch nodes, and point-to-point links. The WAN cloud behaves similarly to the link 
objects in that it delivers frames and models a delay of these frames across the network. 
The cloud’s internal structure is defined using access links and virtual circuits. The 
access links provide the point-of-presence to the WAN cloud. The virtual circuits are 
optional within the cloud, but may be used to specify the grade of service that frames sent 
across the cloud will receive. 

A WAN cloud may be created by either using the toolbar or by choosing the 
Cloud option from the Create menu. Manipulation of the WAN cloud is similar to 
manipulating a subnetwork. To edit the detail of a cloud, the cloud icon must first be 
selected using the mouse, and the Detail option then chosen from the Edit menu. The 
window shown in Figure 8.3 will appear when this is done. Within this window, the 
parameters field allows selecting the parameter set which governs the framing 
characteristics and discard eligibility of frames traversing the network. The interval for 
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mean statistics field specifies in seconds the interval over which statistics on the burst 
size is collected when running a simulation. This interval may be changed while running 
a simulation to adjust the sampling rate. The lower half of Figure 8.3 contains fields 
which become activated when the enhanced model option is chosen for the parameter set 
selected for the cloud. These fields may be used to define when changes in the congestion 
level of the cloud will occur when running a simulation. The three congestion states 
which may be modeled are normal, moderate, and extreme. The congestion state sets the 
delay of frames across the cloud and the probability that a frame will be dropped within 
the cloud. The simulation time that a state change is to occur may be specified along with 
the time the change will take to occur and the time to recover from this change. State 
changes from either moderate or extreme congestion will always be back to a state of 
normal congestion. The probability of extreme congestion may also be specified. A 
random number is pulled from a uniform (0,1) distribution and compared to the extreme 
congestion probability to determine what the next state will be. In essence, these 
parameters allow modeling delays on a network due to additional traffic without having 
to model the traffic itself. 



Figure 8.3 Cloud Detail Window 
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To define the internal structure of the WAN cloud either double click on the 
WAN cloud icon or select the icon and then choose the Enter option from the Edit menu. 
A clear work area will appear which allows creating the access hnks and virtual circuits 
within the cloud. To return back to the backbone view, either double click on the 
background in the work area or select the Leave option from the Edit menu. 

1. WAN Cloud Parameter Sets 

A WAN cloud parameter set defines the framing characteristics which are used 
within the cloud, the probability of frames being dropped within the cloud, and the delays 
associated with traversing simulated switches in the cloud. The parameter set may be 
defined by choosing the WAN Cloud Parameters option from the Define menu, or by 
pressing the button next to the parameter field in the cloud detail window. Either 
method will cause the window shown in Figure 8.4 to appear. The fields of this window 
govern the operating characteristics of the cloud and are used for the following purposes 
[Ref 2 p. 39,40]: 



Figure 8.4 WAN Cloud Parameters Window 
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• Enhanced Model box: Activates the enhanced modeling capabilities of the 
cloud when checked. 

• Session limit: Specifies the number of sessions which may be concurrently 
routed through the cloud at a single time. 

• Frame Min, Max, and Overhead: These fields specify the maximum and 
minimum payload capability and the associated overhead caused by the 
encapsulation of packets which are to be sent across the cloud. The maximum 
and minimum frame sizes are inclusive of the frame overhead. 

• Frame priority: Specifies the manner that frames will be treated when arriving 
at the access link buffer. The frame priority may be set to none which treats all 
frames as equals, equal to the original frame priority, or based on the discard 
eligibility of the frame. 

• Use CIR in VCs box: This mode is the default mode for calculating the burst 
interval for a virtual circuit. If enhanced modeling is chosen, the option is 
available to deselect the box. If deselected, the burst interval for virtual 
circuits must be specifically set. 

• Transmit Non-VCs box: The default operation of a cloud is to transmit frames 
whether or not a virtual circuit is defined in the cloud. This box may be 
deselected when the enhanced modeling option is set. When deselected, 
frames will only be delivered along the defined virtual circuits. 

• Routing Interval: Used with the enhanced modeling option to specify a 
random interval between the updating of the number of switches present in a 
virtual circuit. This feature is used to model variation as a result of varying 
lengths across different paths within a network. 

• Delay/switch: Used to specify the delay a frame will incur as it traverses 
switches in a virtual circuit. The delay may be modeled as a constant or by 
using a statistical distribution. Different values may be specified for the three 
congestion levels when enhanced modeling is used. 
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• Frame drop probability: Specifies the probability of a frame being dropped by 
the network based on the congestion state of the cloud and the discard 
eligibility (DE) of the frame. 

2. Cloud Access Links 

The cloud access link is used to model the access line from a local area network to 
the wide area network’s point of presence. Access links are created within the WAN 
cloud by either using the point-to-point link icon on the toolbar or by selecting the 
Cloud/Access Link option from the Create menu. Each access link created must be 
attached to an access point. The access point is an extension of the access link which 
allows connecting the access link to a node in the backbone view. 

Editing an access link will cause the window shown in Figure 8.5 to appear. The 
fields of this window set the high level operating characteristics of the access link and are 
used for the following purposes: 



Figure 8.5 Cloud Access Link Parameters Window 

• Number of circuits: Specifies the total number of circuits modeled by the 
access link. 

• Entry and Exit bandwidth / circuit: Specifies the transmission rate to and from 
a node and the WAN cloud. 

• Propagation: Used to model the delay from the local area network to the wide 
area network’s point of presence. 
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• Exit buffer: Specifies the link buffer size which is available to frames entering 
the access link from within the WAN cloud. 

• Drop lower priority frames box: If checked, the buffer will drop lower priority 
frames in the buffer queue if the space made available by dropping packets 
will allow higher priority frames to enter the buffer. 

3. Virtual Circuits 

Virtual circuits are optional within the WAN cloud as long as the “Transmit Non- 
VCs” box is checked for the parameter set chosen for the cloud. The main purpose of the 
virtual circuit is to specify the traffic burst constraints which allows evaluating grade of 
service for the wide area network. Burst constraints are set using the following 
parameters: 

• Committed Information Rate (CIR): The maximum sustained subscriber 
throughput rate the network commits to supporting per virtual circuit. [Ref. 8]. 
CIR is expressed in units of kilobits per second. 

• Continuous Burst Size (Be): The maximum number of bits which are 
committed or guaranteed to be transmitted over a burst interval if received 
contiguously by the switch [Ref. 8]. 

• Excess Burst Size (Be): An additional number of bits above the Be which will 
be allowed to be transmitted if the bandwidth is available on the network 
[Ref. 9]. 

• Burst Interval (Tc): The time interval over which the virtual circuit is 
monitored for grade of service. The time interval is normally calculated as 
Bc/CIR. 

The burst constraints specified for a virtual circuit within COMNET III will cause one of 
three things to occur to a frame entering the network when running a simulation. If the 
frame results in exceeding the committed plus excess burst size, the frame is 
automatically dropped. If the frame results in a burst size only greater than the committed 
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burst size, the frame is marked as discard eligible (DE). If less than the committed burst 
size, the frame is marked as normal. 

Virtual circuits may be created only within the WAN cloud and are used to 
connect two access links within the cloud. They provide data flow in only one direction. 
Thus, for two way data flow, two virtual circuits connected in opposite directions would 
need to be modeled. Virtual circuits are created by either using the toolbar, or by choosing 
the Cloud VC option from the Create menu. Editing of the virtual circuit will cause the 
window shown in Figure 8.6 to appear. The fields associated with this window are used 
for the following purposes: 



Figure 8.6 Cloud Virtual Circuit Window 

• Committed Information Rate (CIR): Specifies the maximum sustained 
throughput of the virtual circuit in kilobits per second. This value, along with 
the committed burst size value, provides the default method for calculating the 
burst interval. If enhanced modeling is used and the “Use CIR in VCs” box is 
not checked in the WAN cloud parameters window, this field changes to allow 
explicit setting of a burst interval. 

• Committed burst size: Specifies the threshold on burst size above which 
frames will be marked as discard eligible. 

• Excess burst size: Specifies the threshold above the committed burst size 
which will cause frames to be dropped immediately if exceeded. 
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• Propagation delay; Used to set a delay which models the time required for a 
frame to traverse the distance between access links. 

• Number of switches: Used to set the number of switches the path of the 
virtual circuit may contain when enhanced modeling is used. Otherwise, the 
number of switches is assumed to be one. 

• Show burst size: Checking this box will cause the burst size of the virtual 
circuit to be displayed in the work area when running a simulation. This value 
is updated based on the update interval specified in the cloud detail window. 

E. PACKET ROUTING PROTOCOLS 

As packets traverse the networks defined in the backbone and subnetwork views 
created, routing decisions must be made for a packet to reach its final destination. The 
routing protocols which are built into COMNET HI include: 

• IGRP 

• Link-State Shortest-Path First 

• RIP Minimum Hop 

• Minimum Penalty 

• Shortest Delay 

• User-Defined Routing Tables 

Different routing protocols may be defined for the backbone network and for each 
subnetwork. Routing protocols are set for the backbone network by choosing the 
Backbone Routing option from the Define menu or by selecting the Parent option from 
the Edit menu when in the backbone view. This will bring up the window shown in 
Figure 8.7 which allows setting the packet routing protocol to be used at the backbone 
level and the interval for updating routing tables when running a simulation. Subnetwork 
routing protocols and update intervals are set in the subnetwork detail window as show in 
Figure 8.2. 

When a simulation is first started, each node in the model calculates all possible 
routes to other nodes within its subnet. A routing table is then created which lists the hops 
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Figure 8.7 Backbone Detail Window 

required along a given path to reach a destination. The hops are weighted based on the 
routing protocol chosen. When a packet requires routing, the hops in the table are 
evaluated in the order in which they appear in the table using the following 
logic [Ref. 2 p. 171]: 

• The hop limit for the routing class must not be exceeded. 

• Both the node and the link associated with a hop must be up. 

• The hop must not return to a previously visited node. 

• If a session setup packet is being routed, the link and next node must be under 
there session limit. 

If the tests for a hop are passed, the packet is attempted to be routed along that path. 
Similar decisions occur at each node along the path until the packet reaches its 
destination. If the first hop did not pass the test, the other hops are evaluated in sequential 
order until a hop is found. If all hops fail, the packet is blocked. 

Several of the routing protocols allow specifying a deviation percent which may 
be used to balance traffic load among several links. The deviation percentage sets similar 
hops whose weighting factor falls within the deviation percent to the same weighting 
factor. These hops are then alternated in a round robin order to balance the loads between 
the links. 
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1. IGRP 

The IGRP method calculates weighting factors in the routing tables based on a 
link’s bandwidth, utilization, and delay. The weighting factors are calculated using the 
following equation [Ref. 2 p. 172]: 

K1 * bandwidth factor + K2 * bandwidth factor/(256 - load) + K3 * delay factor 

• Kl, K2, and K3 are specified by the routing class of a packet. The default 
values are 1,0, and 1, respectively. 

• Bandwidth factor = 10’°/bandwidth 

• Load = utilization percent * 255 

• Delay factor = link delay in units of 10 microseconds 

2. Link-State Shortest-Path First 

The Link-State Shortest-Path First protocol calculation of hop weighting factors is 
based on penalty tables applied to the links in the model. Only the penalty values of the 
first line of the penalty table are used. The weighting factor of each hop remains constant 
throughout the entire simulation. The deviation percent is used with this routing protocol 
based on the penalty calculated for a hop. 

a. Penalty Tables 

The penalty table allows a method of applying penalties to links. The 
penalty values used may represent the distance covered by the link, cost of using the link, 
or any other metric needed to be modeled. The penalties applied to a link may be based 
on either the routing class of the packet, the link delay, or the link utilization. The penalty 
tables created are applied to a link by specifying the penalty table to be used in the port 
which is attached to the link. 

Penalty tables are created by choosing the Routing Penalties option from 
the Define menu. This will cause the window shown in Figure 8.8 to appear. By pressing 
the Add button in this window, the window shown in Figure 8.9 will appear which 
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allows creating the penalty table. The threshold field allows entering the values based on 
link utilization or delays. Penalties based on the routing class may be set for each 
threshold value defined. A default column is always present which applies a penalty to 
each routing class listed unless a different penalty value is assigned. 



Figure 8.8 Packet Routing Penalties Window 



Figure 8.9 Packet Routing Penalty Table Window 

3. RIP Minimum Hop 

RIP Minimum Hop calculates weighting factors based on the number of hops 
required along the path of a packet from its origin to its destination. The first route 
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available with the lowest hop count is used. The deviation percent is based on the total 
hop count of a route. 

4. Minimum Penalty 

Minimum penalty routing calculates weighting factors based on penalty tables 
applied to links. It is similar to Open-State Shortest-Path First routing except all rows 
defined in a penalty table are used in determining weighting factors for a hop. The hop 
weighting factors are calculated at the beginning of a simulation and are updated based on 
the interval set in the subnetwork or backbone detail windows. Deviation percent is 
based on the penalty metric used for the route. 

5. Shortest Delay 

Shortest Delay routing calculates weighting factors based on the packet delays 
experienced on a link. Routing tables are updated to account for congestion changes on a 
link based on the interval specified in the subnetwork or backbone detail windows. 
Deviation percent is based on the total link delay of all hops along a'route. 

6. User-Defined Routing Tables 

When user-defined routing is used, routes are selected based on routing tables 
created at nodes in the model. To create the routing tables, the user-defined routing option 
must first be selected in the backbone or subnetwork detail window.'This activates the 
Packet Routing Table button in the node detail window for ATM switch, router, and 
computer and communication nodes. When this button is pressed, the window shown in 
Figure 8.10 will appear. By highlighting a destination in this window, routes to that 
destination may be specified after pressing the Edit Selected button which will cause the 
window shown in Figure 8.11 to appear. The left half of this window is used to define 
various routes, specify the routes as either primary or secondary routes, and to specify the 
order in which these routes are placed in the table which affects the order in which routes 
are looked at when running a simulation. The right half of the window allows building the 
routes which are desired to be specified. When more than one route is set to a destination. 


170 



Figure 8.10 Packet Routing Table Window 



Figure 8.11 Edit Routes Window 
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selection criteria is required to determine which route will be used. The selection criteria 

may be based on the following options; 

•First Available Route 
•Maximum Unused Bandwidth 
•Minimum Delay 
•Minimum Queue 
•Minimum Sessions 
•Random List 
•Round Robin 

F. PROBLEM STATEMENT AND ANALYSIS 

Desktop video conferencing using the multicast backbone (MBONE) is becoming 
highly popular especially in university environments as the availability of workstations 
with adequate processing power and built-in audio capability are becoming more 
common. Frame relay is also becoming a common method of packet switching for public 
and private wide area networks, but has not been tested for use as part of the multicast 
backbone. In order to determine if frame relay would be a suitable method of transport 
between local area networks, a what-if scenario is used to determine the probable delays 
in transmission of multicast video packets across a frame relay network. Discussion with 
Professor Donald P. Brutzman of the Naval Post Graduate School who has done 
extensive research in the multicast backbone indicated that delays in area of 1 second are 
usually tolerable when receiving multicast video. 

The multicast packets generated from desktop video conference sessions on a 
local area network are first sent to network’s multicast router. The multicast router then 
retransmits the packets to all nodes in the network and to other multicast routers on 
separate local area networks. The connections between different multicast routers are 
defined by specifying virtual tunnels within the wide area network. A major concern with 
the transmission of multicast packets is the possible flooding of a network with multicast 
packets. To control this problem, the multicast backbone utilities avmlable require setting 
a time-to-live for packets generated by each session. A time-to-live of 16 would limit 
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packets to a campus-sized area, while a time-to-live of 127 to 255 could send the packets 
worldwide [Ref. 9]. 

To model the possible use of a frame relay wide area network, two separate 
models will be built. One model will use a WAN cloud to model the wide area network, 
and the other will use ATM switch nodes and point-to-point links to build the network. 

To model the generation of video packets, the data used and discussed in Chapter Vn will 
be used. Three separate local area networks connected by the wide area network will be 
modeled. Each local area network will consist of a two nodes generating video packets 
and a multicast router attached to a FDDI network. Two message sources will be used to 
model the routing required by the multicast router. One message source will model the 
routing of packets received from the wide area network. The other message source will 
model the routing of video packets generated within the local area network. 

A problem with modeling multicast video packets in COMNET IE is that the 
application does not have a method of specifying a time-to-live of a packet. A method to 
work-around this problem is to use routing classes to specify a hop limit for a routing 
class which will minimize the total distance a packet may travel. 

The message generator used to create video packets is based on the data collected 
from a workstation set to transmit video packets at a rate of 128 kbps. As two nodes each 
will be generating packets within a local area network, the tunnel from the network to the 
wide area network and the links in the wide area network will be modeled as having a 
transmission rate of 256 kbps. The tunnel from the wide area network to the local area 
network will be modeled as having a transmission rate of 512 kbps. 

G. BUILDING THE NETWORK MODELS 

Three separate models will be built to model the transmission of video packets 
across a frame relay wide area network. The first model will be used to create the local 
area networks and message sources. This model will then be used in the two other models 
where the wide area network will be added. One of the models will use the WAN cloud to 
model the frame relay network. In the other model, the wide area network will be built 
using ATM switch nodes and point-to-point links. 
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1. Defining Computer and Communication Node Parameter Sets 

The computer and communication parameter set defined will be used for all 

computer and communications nodes created in the model. 

a) Select the Node Parameters/Computer and Communications option from the Define 
menu. In the computer and communications node parameters window which appears 
press the Add button. Edit the following fields in the node parameter window which 
appears: 

• Name: WORKSTATION 

• Time slice: Set to a uniform distribution with a minimum of 10000 and a 
maximum of 1000000. The stream value may be set to any integer from 0 to 
99. 

• Port processing default times: Set to 0.005 milliseconds for both input and 
output. 

2. Creating the Local Area Network Topology 

The local area network topology will be created within a subnetwork. Each of the 

three local area networks which will be modeled in exactly the same manner. 

a) Create a subnetwork using the toolbar. Change the name of the subnetwork SANTA 
CRUZ. 

b) Enter the subnetwork and create a token passing link. Edit the parameters of the link 
to the following: 

• Name: UCSC FDDI 

• Type: Token Passing 

• Parameters: FDDI 

c) Create three computer and communication nodes in the work area and edit the fields 
in the node detail window for each to those values shown in Table 8.1. Attach each 
node to the UCSC FDDI link. 

d) Create an access point using the toolbar and attach the access point to the node 
UCSC2 MBONE ROUTER. 
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Name 

Type 

Parameter 

UCSCl 

C&C Node 

WORKSTATION 

UCSC2 MBONE ROUTER 

C&C Node 

WORKSTATION 

UCSC3 

C&C Node 

WORKSTATION 


Table 8.1 Local Area Network Computer and Communication Node Parameters 


3. Deflning the NetVideo Message Source Tabular Distributions 
The tabular distributions created will be used to describe the message size and 
interarrival times of the NetVideo message source. 

a) From the Define menu select the Tables option. 

b) Press the Add button in the tabular distributions window, and edit the fields of the 
table detail window to the following; 

• Name: NVSIZE-TAB 

• Table type: discrete 

• Probabilities and Values: Enter the cumulative probabilities and packet size 
from Table 8.2 into the probability and values fields respectively. 


Packet Size (bytes) 

Probability 

Cumulative Probability 

20 

0.03 

0.03 

50 

0.01 

0.04 

340 

0.07 

0.11 

1050 

0.13 

0.24 

1060 

0.17 

0.41 

1070 

0.13 

0.54 

1080 

0.11 

0.65 

1090 

0.09 

0.74 

1100 

0.08 

0.82 

1110 

0.06 

0.88 

1120 

0.04 

0.92 

1130 

0.03 

0.95 

1140 

0.02 

0.97 

1150 

0.01 

0.98 

1160 

0.01 

0.99 

1170 

0.01 

1.00 


Table 8.2 Packet Size and Probabilities 


c) When all fields are entered, press the OK button at the bottom table detail window. 
Then, press the Add button in the tabular distributions window to create the second 
distribution. 
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d) Edit the fields of the table detail window to the following: 

• Name; NVINTER-TAB 

• Table type; discrete 

• Probabilities and Values: Enter the cumulative probabilities and packet size 
from Table 8.3 into the probability and values fields respectively. 

e) When all fields are entered, press the OK button at the bottom table detail window. 
Then, press the Done button in the tabular distributions window to create the second 
distribution. 


Packet Interarrival Time (seconds) 

Probability 

Cumulative Probability 

0.01 

0.022 

0.022 

0.02 

0.015 

0.037 

0.03 

0.018 

0.055 

0.04 

0.076 

0.131 

0.05 

0.052 

0.183 

0.06 

0.107 

0.290 

0.07 

0.294 

0.584 

0.08 

0.172 

0.756 

0.09 

0.022 

0.778 

0.10 

0.008 

0.786 

0.11 

0.012 

0.798 

0.12 

0.008 

0.806 

0.13 

0.046 

0.852 

0.14 

0.069 

0.921 

0.15 

0.025 

0.946 

0.16 

0.005 

0.951 

0.17 

0.002 

0.953 

0.18 

0.004 

0.957 

0.19 

0.003 

0.960 

0.20 

0.015 

0.975 

0.21 

0.015 

0.990 

0.22 

0.002 

0.992 

0.25 

0.001 

0.993 

0.26 

0.003 

0.996 

0.27 

0.002 

0.998 

0.28 

0.002 

1.000 


Table 8.3 Packet Interarrival Times and Probabilities 
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4. Deflning Routing Classes 

The routing classes defined using the following steps will be used to specify hop 
limits for the multicast packets generated by the routing and generation of multicast video 
packets. 

a) From the Define menu select the Routing Class/ Packets option. In the packet routing 
classes window which appears, press the Add button. 

b) Edit the following fields in the packet routing class window. 

• Name: MBONE 1 

• Hop limit: 1 

c) When all fields are entered, press the O.K'button in the packet routing class window. 
Then, press the Add button in the packet routing classes window again. 

d) Edit the following fields in the packet routing class window. 

• Name: MBONE 6 

• Hop limit: 6 

e) When all fields are entered press the OK button in the packet routing class window. 
Then, press the Done button in the packet routing classes window. 

5. Creating the NetVideo Message Source 

The NetVideo message source will be used to model the broadcast of multicast 
packets for desktop video conferencing. 

a) Create a message source, and edit the fields of the message source window to those 
shown in the following list. Figure 8.12 depicts the message source window upon 
completion. 

• Name: UCSC NET VIDEO 

• Schedule by: Iteration time 

• Interarrival: NVINTER-TAB 

• Message size calculation: Probability distribution 

• Probability distribution: NVSIZE-TAB 

• Priority: 1 

• Routing class: MBONE 1 

• Transport protocol: UDP/IP-Sun 

• Packetize: 0.05 milliseconds 

• Message text option: Copy message name 

• Destination type: Set to multicast list, and create a list containing only the 
node UCSC2 MBONE ROUTER. 
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Figure 8.12 NetVideo Message Source 


b) When all fields have been entered, press the OK button at the bottom of the message 
source window. 

c) Create a clone of the NET VIDEO message source. 

d) Attach one copy of the message source to the node UCSC1 and the other to the node 
UCSC3. 

6. Creating the Multicast Routing Message Sources 

The multicast router will route packets both within the local area network and to 
other multicast networks across the wide area network. Two message sources are 
necessary to model routing both in and out of the local area network. The following steps 
outline the steps for creating these sources: 

a) Create a message source and attach it to the node UCSC2MBONE ROUTE. 

b) Edit the fields of the message source window to those shown in the following list. 
Figure 8.13 depicts the message source upon completion. 

• Name: UCSC MBONE INT ROUTING 

• Schedule by: Received message. The received message list will be created 
later. 
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• Priority: 1 

• Routing class: MBONE 1 

• Transport protocol: UDP/IP-Sun 

• Packetize: 0.05 milliseconds 

• Message size calculation: (A * Msg bytes) + B 

• A: 1.000 

• B: 0.000 

• Message text option: Use original message 

• Destination type: Set to multicast list, and create a list containing only the 
nodes UCSCl and UCSC3. 



Figure 8.13 MBONE INT ROUTING Message Source 


c) When all fields are entered, press the OK button at the bottom of the message source 
window. 

d) Create a copy of the UCSC MBONE ROUTING message source and attach the copy 
to the node UCSC2 MBONE ROUTER. Change the following fields of this message 
source: 

• Name: UCSC MBONE EXT ROUTING 

• Routing Class: MBONE 6 
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e) The internal structure of the first local area network is now completed with the 
exception of defining the received message lists and destinations for the message 
sources which will be used for routing. The view inside the SANTA CRUZ 
subnetwork should look similar to that of Figure 8.14. 



7. Creating the Other Local Area Networks 

The two other local area networks are identical to the local area network created 
in the SANTA CRUZ subnetwork. These additional networks will be created by cloning 
the SANTA CRUZ subnetwork and then renaming the nodes inside the subnetwork. 

a) Leave the SANTA CRUZ subnetwork view to return to the backbone view. 

b) Select the SANTA CRUZ subnetwork and make two clones of this subnetwork. 
Rename the cloned subnetworks MONTEREY and SAN FRANCISCO. 

c) Enter the MONTEREY subnetwork and rename the nodes and message sources 
within the subnetwork to those shown in Table 8.4. After all the nodes and message 
sources have been renamed in the MONTEREY subnetwork, leave this subnetwork 
and enter the SAN FRANCISCO subnetwork. Rename all of the nodes and message 
sources in this subnetwork to those shown in Table 8.4. 
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d) The received message lists and destination list for each message source created are 
listed in Table 8.5. Enter and leave the subnetworks as necessary to create these 
received message lists and destination lists. 


SANTA CRUZ Subnetwork 
Name 

MONTEREY Subnetwork 
Name 

SAN FRANCISCO 
Subnetwork Name 

UCSCl 

NPSl 

STANFORD1 

UCSC2 MBONE ROUTER 

NPS2 MBONE ROUTER 

STANFORD2 MBONE 
ROUTER 

UCSC3 

NPS3 

STANFORD3 

UCSC NET VIDEO 

NPS NET VIDEO 

STANFORD NET VIDEO 

UCSC MBONE INT 

NPS MBONE INT 

STANFORD MBONE INT 

ROUTING 

ROUTING 

ROUTING 

UCSC MBONE EXT 

NPS MBONE EXT 

STANFORD MBONE EXT 

ROUTING 

ROUTING 

ROUTING 


Table 8.4 Subnetwork Node and Message Source Names 


Message Source 

Received Message List 

Destination List 

UCSC NET VIDEO 

N/A 

UCSC2 MBONE ROUTER 

UCSC MBONE INT 
ROUTING 

NPS NET VIDEO, 
STANFORD NET VIDEO 

UCSCl, UCSC3 

UCSC MBONE EXT 
ROUTING 

UCSC NET VIDEO 

NPS2 MONE ROUTER, 
STANFORD2 MBONE 
ROUTER, UCSCl, UCSC3 

NPS NET VIDEO 

N/A 

NPS2 MBONE ROUTER 

NPS MBONE INT 
ROUTING 

UCSC NET VIDEO, 
STANFORD NET VIDEO 

NPS1,NPS3 

NPS MBONE EXT 
ROUTING 

NPS NET VIDEO 

UCSC2 MONE ROUTER, 
STANFORD2 MBONE 
ROUTER, NPSl, NPS3 

STANFORD NET 
VIDEO 

N/A 

STANFORD2 MBONE ROUTER 

STANFORD MBONE 
INT ROUTING 

UCSC NET VIDEO, NPS 
NET VIDEO 

STANFORDl, STANFORD3 

STANFORD MBONE 
EXT ROUTING 

STANFORD NET VIDEO 

UCSC2 MONE ROUTER, NPS2 
MBONE ROUTER, 
STANFORDl, STANFORD3 


Table 8.5 Received Message Lists and Destination Lists for Message Sources 


e) The local area network topologies and the message sources are all now completed. 
Verify the model. A list of errors will appear that should only contain errors stating 
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that the subnetworks are not connected to any links within the model. Save the model 
using the name mbone6.c3 . 

8. Modeling the Wide Area Network Using ATM Switch Nodes and Point- 
To-Point Links 

The following section defines the steps for modeling the wide area network using 
switches and point-to-point links. This model should look similar to Figure 8.15 upon 
completion. 

a) Save the model mhone6.c3 using the name mhone6a.c3 to create a new model. 

b) Select the Node Parameters/ATM option from the Define menu. In the ATM 
parameters window which appears press the Add button. Edit the fields in the second 
ATM parameters window which appears to the following: 

• Name: POP SWITCH 

• Port processing default times: Set to 0.005 milliseconds for both input and 
output. 

c) Create and ATM switch node in the backbone view and edit the fields of the node 
parameters window to the following: 

• Name: SANTA CRUZ SWITCH 

• Type: ATM Node 

• Parameters: POP SWITCH 
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d) Create two copies of the SANTA CRUZ SWITCH ATM node. Rename these copies 
MONTEREY SWITCH and S.F. SWITCH. 

e) Select the Link Parameters/Point-to-Point option from the Define menu. In the point- 
to-point parameters window which appears press the Add button. In the library 
selection window which appears choose default in the list. 

f) Edit the fields of the point-to-point parameters window to the values shown in the 
following list. Figure 8.16 depicts the parameter set upon completion. 

• Parameter set name: 256 KBPS FRAME RELAY 

• Number of circuits: 1 

• Bandwidth/circuit (from node X): 256 

• Bandwidth/circuit (from node Y): 256 

• Frame min: 13 

• Frame max: 4108 

• Frame overhead: 12 



Figure 8.16 256 Kbps Frame Relay Point-To-Point Link Parameter Set 


g) Create a second point-to-point link parameter set in the same fashion as the first using 
the following values: 
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• Parameter set name: 256/512 KBPS FRAME RELAY 

• Number of circuits: 1 

• Bandwidth/circuit (from node X): 256 

• Bandwidth/circuit (from node Y): 512 

• Frame min: 13 

• Frame max: 4108 

• Frame overhead: 12 

h) Create a point-to-point link and attach the link to the SANTA CRUZ subnetwork and 
the SANTA CRUZ SWITCH node. Edit the fields in the link detail window of this 
point-to-point link to the following: 

• Name: SANTA CRUZ ACCESS 

• Type: point-to-point 

• Parameters: 256/512 KBPS FRAME RELAY 

i) Create two copies of the SANTA CRUZ ACCESS link. Rename one copy 
MONTEREY ACCESS and attach it to the MONTEREY SWITCH node and the 
MONTEREY subnetwork. Rename the other copy S.F. ACCESS and attach it to the 
S.F. SWITCH node and the SAN FRANCISCO subnetwork. 

j) Create another point-to-point link and attach it to the SANTA CRUZ SWITCH and 
MONTEREY SWITCH nodes. Edit the fields of the link detail window to the 
following: 

• Name: SC - MONTEREY 

• Type: point-to-point 

• Parameters: 256KBPS FRAME RELAY 

k) Create two copies of the SC - MONTEREY link. Rename one copy S.F. - 
MONTEREY and attach it to the MONTEREY SWITCH node and the S.F. 
SWITCH . Rename the other copy SC - S.F. and attach it to the S.F. SWITCH node 
and the SANTA CRUZ SWITCH. 

l) The second model is now completed. Verify and save the model. 
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9. Modeling the Wide Area Network Using a WAN Cloud 
The following steps outline the method for modeling the frame relay wide area 
network using a WAN cloud. The backbone view of the model should look similar to 
Figure 8.17 upon completion. 



a) Open the model mbone6.c3 and save it using the name mhone6c.c3. 

b) Create a WAN cloud and place it in the work area. Select the cloud and choose the 
Detail option from the Edit menu. Edit the following fields in the cloud detail 
window: 

• Name: FRAME RELAY WAN 

• Type: WAN Cloud 

• Parameters: Frame Relay 

c) Enter the WAN cloud. 

d) From the Define menu choose the WAN Cloud parameters/Access Link option. Edit 
the fields in the cloud access link parameters window to the values shown in the 
following list. Figure 8.18 depicts the access link parameter window upon 
completion. 

• Parameter set name: 256/512 KBPS ACCESS 

• Number of circuits: 1 

• Entry bandwidth/circuit: 256 

• Exit bandwidth/circuit: 512 

• Exit buffer: 16834 
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Figure 8.18 Cloud Access Link Parameter Window 


e) Create an access link within the WAN cloud. Edit the following fields in the access 

link window: 

•Name: SANTA CRUZ 
•Parameters: 256/512 KBPS ACCESS 

f) Create two copies of the SANTA CRUZ access link. Rename the links MONTEREY 
and SAN FRANCISCO. 

g) Create three access points in the WAN cloud. Attach one to each of the access links. 

h) Create one virtual circuit in the WAN cloud. Edit the fields for this circuit to the 
values shown in the following list. Figure 8.19 depicts the circuit parameters upon 
completion. 



Figure 8.19 Virtual Circuit Parameters 
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• Name: SC TO MONTEREY 

• Committed info rate: 256 

• Committed burst size: 256 

• Excess burst size: 2 

• Show burst size box: checked 


i) Create five clones on the SC TO MONTEREY virtual circuit. Rename the circuits 
according to the names shown in Table 8.6 and connect the access point as listed in 
the same table. It is important that the virtual circuits be connected as per the table as 
they are one way circuits. Figure 8.20 depicts a view of the interior of the WAN cloud 
with all access links and virtual circuits defined. 


Name 

From Access Link 

To Access Link 

sc TO MONTEREY 

SANTA CRUZ 

MONTEREY 

MONTEREY TO SC 

MONTEREY 

SANTA CRUZ 

MONTEREY TO S.F. 

MONTEREY 

SAN FRANCISCO 

S.F. TO MONTEREY 

SAN FRANCISCO 

MONTEREY 

SC TO S.F. 

SANTA CRUZ 

SAN FRANCISCO 

S.F.TO SC 

SAN FRANCISCO 

SANTA CRUZ 


Table 8.6 Virtual Names and Access Link Connections 
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j) Leave the WAN cloud and attach each of the access points of the WAN cloud an 
access point on one subnetwork. 

k) This model is now completed. Verify and save the model. 

H. SIMULATION AND RESULTS 

For each model, one simulation replication was run for each model using a 
simulation time of 60 seconds and a warmup length of 5 seconds. Prior to running the 
simulation the following reports were selected: 

• Link Reports; Channel Utilization for all links in both models. 

• WAN Cloud Reports; Frame Delay by VC, Frame Count by VC, and Access 
Link Statistics for the model containing the WAN cloud.' 

• Message and Response Source reports: Message Delay for all message sources 
in both models. 

The results of the two simulations in determining the delay across the wide area 
network differed by 15 milliseconds. The WAN cloud model had an average delay across 
the network of 62 milliseconds while the total average delay across all links in the wide 
area network was 77 milliseconds. Both simulations showed that the ability of the 
multicast router to process and resend packets very rapidly will greatly affect the delays 
of the video packets. The simulations do show that the transmission of video packets 
across a frame relay network should be possible. Which method of modeling the wide 
area network is better? The simulation results for both were fairly close. The main 
advantage of using the WAN cloud to model the network is the ease of making a simpler 
model and the ability of the cloud to specify the grade of service of the virtual circuits 
which point-to-point links cannot provide. 
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IX. CONCLUSION 


A. SUMMARY 

The purpose of this thesis was to provide a hands-on tutorial to allow users of the 
COMNET in application to quickly ramp up on the capabilities which this application 
provides to model and simulate local and wide area networks. The COMNET HI Users 
manual contains complete information on the theory and capabilities of each object, but it 
presents no logical structure for understanding the manner in which these objects tie 
together when modeling a network. 

Each chapter presents the theory of several objects which are available for 
modeling networks, presents a network problem which relates to the objects discussed, 
and provides instruction to build a model to demonstrate the ability of COMNET DI to 
analyze network problems. The goal of each model, when possible, was to use 
information which was gleaned from actual networks present on the Naval Postgraduate 
School campus. The primary networks from which data was gathered was the Systems 
Technology Lab’s ethemet and fiber distributed data interface (FDDI) networks. The 
gathering of data was performed using the Snoop protocol analyzer program or by 
conducting interviews with network managers to obtain estimates of the types of traffic 
on the network, current network problems, and commonly used applications which are 
used on computers attached to the network. 

B. COMNET III APPLICABILITY WITfflN THE MILITARY 

If the current trend toward the use of commercial technology for the development 
of military networks continues, COMNET HI could have wide applicability in assisting in 
the design and performance analysis of packet-switched and local area networks used by 
the military. Operation Desert Shield/Desert Storm provides good evidence that this trend 
will continue as military personnel brought not only the weapons necessary to fight the 
war but also their personal computers. To meet the information needs in this conflict, 
Hewlett Packard workstations were used to act as gateways for ad hoc wide area networks 
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and local area networks which provided connectivity between personal computers used by 
the GENICOM staff. 

The other major factor which makes simulation of networks a needed tool 
available within the military is the shrinking Department of Defense budget combined 
with an increased dependence within the military on the ability to transfer information to 
any level that it may be needed in a timely manner. COMNET IE’s graphical user 
interface allows users to quickly develop network models which may be used to assess 
high level performance measures of a network. Proposed network designs could be 
modeled to assess their suitability and reliability in delivering data and necessary 
adjustments made prior to a network being physically built. This would provide great cost 
saving in minimizing network modifications. 

C. RECOMMENDED FUTURE STUDIES 

While conducting research to develop the models presented in this thesis, two 
major problems were encountered which hindered the development of truly high fidelity 
models within the application. 

The first major problem occurred while collecting data to model traffic and 
application sources. Interviews with various network managers throughout the campus 
indicated that little is known about the characteristics of the traffic which is carried 
throughout the networks located at the Naval Postgraduate School. Network monitoring 
tools are currently in their infancy. Many tools do exist which allow the capturing of 
packets from a network for off-line analysis, recording the number of requests to a web 
server, or determination of the network utilization over a period of time. However, no 
application could be found which provided the capability to conduct detailed traffic 
analysis on-line which could provide source, destination, frame size, and interarrival 
times of traffic across a network which are the necessary pieces of information needed to 
effectively model traffic in COMNET in. The HP OpenView suite of network 
management modules, had they been available, seemed to have the most promising 
features for gathering data which may be used to model network traffic. The development 
of such a tool would be highly useful not only for the modeling of traffic within 
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COMNET in, but also for the management and configuration changes to local area 
networks. 

The other major problem found was the ability to find the information needed to 
effectively describe the characteristics of the network objects such as computers and 
switches available within the application. The majority of the characteristics needed to 
describe these objects deal with modeling the delays associated with the processing of 
packets. The information is normally not contained within hardware manuals or 
performance specifications. The Harvard Network Device Test Laboratory is currently 
one of the few places which is conducting testing which may be used to model the delays 
of traffic across network devices. Results of their tests were used by CACI Products Inc. 
in developing the library of router parameter sets which are available in COMNET HI. 
The development of tests which could be performed to ascertain the delays which occur 
in the processing of packets by network devices such as computers, switches, and hubs 
would be highly useful for the modeling of network hardware devices. 
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